From owner-freebsd-arm@FreeBSD.ORG Sun Sep 15 00:04:38 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 44991E00 for ; Sun, 15 Sep 2013 00:04:38 +0000 (UTC) (envelope-from lists@eitanadler.com) Received: from mail-pd0-x235.google.com (mail-pd0-x235.google.com [IPv6:2607:f8b0:400e:c02::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 178832348 for ; Sun, 15 Sep 2013 00:04:38 +0000 (UTC) Received: by mail-pd0-f181.google.com with SMTP id g10so2676736pdj.26 for ; Sat, 14 Sep 2013 17:04:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eitanadler.com; s=0xdeadbeef; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=8JacrX3h/FaLvL3ZEh8hc1W/6C0LamNWGB64bozeaK8=; b=ioKs8F+badbfacny8ZGXcN8nbopLlmLQ51Z/uird42yI2ltEfc6zB6SuRLXhQvpFkx l9p0ZXGIoEDYkoeQVmD/Fvwr2+dPqfdLHkcISrGN2YuOsvIdpAj/aIBhHgnNHruQ58PU 8mSLZ0Y42m/4o9nsK/hgO4qhacznaSoBW9gBE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=8JacrX3h/FaLvL3ZEh8hc1W/6C0LamNWGB64bozeaK8=; b=UWNLI5DtpgYSSlhuxJeAeUrK2GMiFIJB6FN91ib24jINHEc19MTESC12qkFguH9TyN /63N1Kok0q/O6TP+6fQpIdfba//5h+EEA7J9VTb7H2IVtJ5xt6rHm80zL3wTFsk5SOlP 4tXvZks7Gbc4poXaLzJPqQ0pYUkmRtdAKGeRbt0BW/nY+zzVyxOQrNhekuHS///iKtLD k4hpqKL6k5MJtx1SDHIOJsM/liW0l1lWqZgrdXab5SaJys7sqm1C2ZAmwnG5eBZshBHV jGxmVB8ygL8Sl9mvM6vNswzh8iHQBp0IDuCU/WeV3otoGbK/Icg0Z85uvglWiP9y8A0L /Lvg== X-Gm-Message-State: ALoCoQn4XHF30473XPRWZTqwtvieiZrx/MjRNsQUMhnkQyLQX4MDEP7PdIr5Ktg+r2Stux8r93NC X-Received: by 10.66.149.231 with SMTP id ud7mr23390826pab.8.1379203477673; Sat, 14 Sep 2013 17:04:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.70.6.3 with HTTP; Sat, 14 Sep 2013 17:04:07 -0700 (PDT) In-Reply-To: References: <522CC7E0.9060508@freebsd.org> <5231D8A6.9080501@freebsd.org> <20130914133155.GA32845@alchemy.franken.de> <52346D71.4080407@freebsd.org> <1379173405.1197.7.camel@revolution.hippie.lan> <20130914172735.GX68682@funkthat.com> <1379181341.1197.26.camel@revolution.hippie.lan> From: Eitan Adler Date: Sat, 14 Sep 2013 20:04:07 -0400 Message-ID: Subject: Re: Patch for Cross-Reference Phandles To: Adrian Chadd Content-Type: text/plain; charset=UTF-8 Cc: freebsd-sparc64 , "freebsd-arm@freebsd.org" , Ian Lepore , FreeBSD PowerPC ML X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Sep 2013 00:04:38 -0000 [ *please* bottom post ] On Sat, Sep 14, 2013 at 7:56 PM, Adrian Chadd wrote: > ... holy crap. :-) > > erm, try writing some code that does something with it: > > int foo[2] = { 0, 0 }; > > main() > { > int i; > for (i = 0; i < 2; i++) { > foo[i] = i; > } > } > > .. and then make foo[2] be foo[512] and explicitly set it up to be zero'ed. > see what happens. With an explicit zeroing: text data bss dec hex filename 1572 484 16 2072 818 a.out Without: text data bss dec hex filename 1572 484 16 2072 818 a.out From owner-freebsd-arm@FreeBSD.ORG Sun Sep 15 00:06:20 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 4A916FCD; Sun, 15 Sep 2013 00:06:20 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wg0-x22e.google.com (mail-wg0-x22e.google.com [IPv6:2a00:1450:400c:c00::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 640212361; Sun, 15 Sep 2013 00:06:19 +0000 (UTC) Received: by mail-wg0-f46.google.com with SMTP id k14so2414222wgh.25 for ; Sat, 14 Sep 2013 17:06:17 -0700 (PDT) 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=E0XxjlbLMKaX/CHLQC0PcQA3kTJ4rWjsReuwJ4hiMbQ=; b=zsm/YrxRWCPX7SOVlwgHwDfM6bIRNrty3aNInkXNzzd3qxrqBAQ5nQJnaEM50IqLvn ZV+dafOybgH2J08doWnjmwg48OuUl4tZ7w+bQMsHB77+4uXV8BkXSZLpP3skG0Mpzcux iSBjZOgkZKSyZlFX4p4d3adtIOBuFjHie7ZPghbeFZzrRWQGZgJb0eqgUCMecMyhIRLc F74AIAMI8p+6qsjNUkHNU6WYthQJM7xXPDdFRq4vCC/7FKuNpGaq2R7ssO2cAgbi8kwK utodiKuAhTv/dEvvDnPep/3Pq0SdR3X7hEYL5f+/P0jBgOZOCLBr6EQGmcaIbYo5o0s0 uwYw== MIME-Version: 1.0 X-Received: by 10.180.93.104 with SMTP id ct8mr8016029wib.0.1379203577684; Sat, 14 Sep 2013 17:06:17 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.216.73.133 with HTTP; Sat, 14 Sep 2013 17:06:17 -0700 (PDT) In-Reply-To: References: <522CC7E0.9060508@freebsd.org> <5231D8A6.9080501@freebsd.org> <20130914133155.GA32845@alchemy.franken.de> <52346D71.4080407@freebsd.org> <1379173405.1197.7.camel@revolution.hippie.lan> <20130914172735.GX68682@funkthat.com> <1379181341.1197.26.camel@revolution.hippie.lan> Date: Sat, 14 Sep 2013 17:06:17 -0700 X-Google-Sender-Auth: 3ZjL3eBGhfUSr1AOW3nlcyZ-Clg Message-ID: Subject: Re: Patch for Cross-Reference Phandles From: Adrian Chadd To: Eitan Adler Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-sparc64 , "freebsd-arm@freebsd.org" , Ian Lepore , FreeBSD PowerPC ML X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Sep 2013 00:06:20 -0000 On 14 September 2013 17:04, Eitan Adler wrote: > With an explicit zeroing: > > text data bss dec hex filename > 1572 484 16 2072 818 a.out > > Without: > > text data bss dec hex filename > 1572 484 16 2072 818 a.out > This is exactly the opposite of what I see with kernel code though. Eg, kern_umtx.c and it's very large up-front allocated array. Same as the upfront array of KTR entries for early boot tracing. Try bumping it to something stupid like 65536 and retest? Is this a gcc-4.2 versus clang difference? Thanks, -adrian From owner-freebsd-arm@FreeBSD.ORG Sun Sep 15 00:24:09 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 09AED417 for ; Sun, 15 Sep 2013 00:24:09 +0000 (UTC) (envelope-from lists@eitanadler.com) Received: from mail-pd0-x235.google.com (mail-pd0-x235.google.com [IPv6:2607:f8b0:400e:c02::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id B31B2242E for ; Sun, 15 Sep 2013 00:24:08 +0000 (UTC) Received: by mail-pd0-f181.google.com with SMTP id g10so2707270pdj.12 for ; Sat, 14 Sep 2013 17:24:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eitanadler.com; s=0xdeadbeef; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=tcMtUpg5iKWGB1hPjwG2t02SVuaORswtgJYT/yWXfwY=; b=C7xQliIO+RcH6aPLCeZvdAq8owOi+fiEiOmvbj6SzWPHJpteu1HRvhb7DlZ+q5TwQz fk+ONLw4+ojjekPzr0teVROnCSjBd7mLbcYcU+VCSzWjTRQnK0Q2a9I+fiLwonT65lgG 1am5InV6wpLfxrUBKJzr5SHLTEOMxmQXonb1I= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=tcMtUpg5iKWGB1hPjwG2t02SVuaORswtgJYT/yWXfwY=; b=f5t6Vfw5sxiRqheadZ8CRXc4pIp956DpPk5PW7yN3/M8S04aS51h7UB+piGCDKgjU0 ZQDu7ypmvYPVI19aUxW7PdueWc+Jh9OsLviGPTBQXE44hZ9uD4LKgf+hkMqlqujQ+Fz4 +7sZIlmEJKK8EDwoZRwwzfQzARsEgHQp3TP/t3ivN4kRMEbqy2aRclvrr3Djvo0a2kza nplBe3x+EQiQVJfA+Cq5V/SszORlE4zJVMVDWLWAVwO/RQx7phnQXKdDPH+u7+r/21Sv ZmvGywqsDbuQKnbBNjLFXkHFlJRVFFeoK0wJmMnm1xEd5Dq4pNA3KU5fLecm/onzjTDY cZSw== X-Gm-Message-State: ALoCoQn3SN/UkI/5AvFjdNuyIdyqivf+me/0geNg2c6iwwamku34eFECnBEDqi5itW1dgp3txoFC X-Received: by 10.68.143.38 with SMTP id sb6mr21242449pbb.44.1379204648068; Sat, 14 Sep 2013 17:24:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.70.6.3 with HTTP; Sat, 14 Sep 2013 17:23:37 -0700 (PDT) In-Reply-To: References: <522CC7E0.9060508@freebsd.org> <5231D8A6.9080501@freebsd.org> <20130914133155.GA32845@alchemy.franken.de> <52346D71.4080407@freebsd.org> <1379173405.1197.7.camel@revolution.hippie.lan> <20130914172735.GX68682@funkthat.com> <1379181341.1197.26.camel@revolution.hippie.lan> From: Eitan Adler Date: Sat, 14 Sep 2013 20:23:37 -0400 Message-ID: Subject: Re: Patch for Cross-Reference Phandles To: Adrian Chadd Content-Type: text/plain; charset=UTF-8 Cc: freebsd-sparc64 , "freebsd-arm@freebsd.org" , Ian Lepore , FreeBSD PowerPC ML X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Sep 2013 00:24:09 -0000 On Sat, Sep 14, 2013 at 8:06 PM, Adrian Chadd wrote: > On 14 September 2013 17:04, Eitan Adler wrote: > >> >> With an explicit zeroing: >> >> text data bss dec hex filename >> 1572 484 16 2072 818 a.out >> >> Without: >> >> text data bss dec hex filename >> 1572 484 16 2072 818 a.out > > > This is exactly the opposite of what I see with kernel code though. Eg, > kern_umtx.c and it's very large up-front allocated array. Same as the > upfront array of KTR entries for early boot tracing. > > Try bumping it to something stupid like 65536 and retest? > > Is this a gcc-4.2 versus clang difference? #ifdef EXPLICIT int foo[65536] = { 0 }; #else int foo[65536]; #endif int main() { int i; for (i = 0; i < 2; i++) { foo[i] = i; } } No optimizations. text data bss dec hex filename 1572 484 262152 264208 40810 clang-explicit 1572 484 262160 264216 40818 clang-implicit 1508 456 262184 264148 407d4 gcc46-explicit 1508 456 262176 264140 407cc gcc46-implicit 1652 456 262184 264292 40864 gcc49-explicit 1652 456 262176 264284 4085c gcc49-implicit I'm not sure of the cause of the 8 byte difference. -- Eitan Adler From owner-freebsd-arm@FreeBSD.ORG Sun Sep 15 05:26:00 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id D77865A0; Sun, 15 Sep 2013 05:25:59 +0000 (UTC) (envelope-from paradyse@gmail.com) Received: from mail-wg0-x230.google.com (mail-wg0-x230.google.com [IPv6:2a00:1450:400c:c00::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 440332EDC; Sun, 15 Sep 2013 05:25:59 +0000 (UTC) Received: by mail-wg0-f48.google.com with SMTP id n12so2522557wgh.27 for ; Sat, 14 Sep 2013 22:25:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=NAT8qlf3l0A456sqDhSknVOuxe4hYGuR+ywXH18bqkI=; b=LbDHLAcseH7J/eCGKt8v9Azg6db9n/Ni2o7sfRMySZHwCHQ+adI9d1t8ssb2bFhmSN zP2IPicKzA2rwKhhfwJ1cKdz5P28nLHrQSMxM1h1tef+S8p6QvJj4zyGy8p89NcLMeq7 3pHB38l5sVF4WvE/xRTP5kUQ+6NGNCGiSEtF8fGyF97HPAvo2Q4wreqycBitMLtiCuvz zeZCWUCuykg9ew8RYBDn2jZBZ+U/6HTgPXziVkUb3ET7rH6Wv/dn3MevWQFJzRcduXou 2XXhK+vWMoF4yTgIDPrGALVpQWLVVp/zHVBhtyEtfJlIN+bZ3llN+wowAix2ZDJayO5F 3TiQ== X-Received: by 10.180.205.236 with SMTP id lj12mr8532641wic.22.1379222757672; Sat, 14 Sep 2013 22:25:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.134.170 with HTTP; Sat, 14 Sep 2013 22:25:27 -0700 (PDT) In-Reply-To: <0AC11ABC-5C40-4C63-B90D-2E686562BFD2@kientzle.com> References: <1379188513.1197.35.camel@revolution.hippie.lan> <0AC11ABC-5C40-4C63-B90D-2E686562BFD2@kientzle.com> From: Su Kang Yin Date: Sun, 15 Sep 2013 13:25:27 +0800 Message-ID: Subject: Re: FreeBSD 10.0-ALPHA1 r255532 bootup freeze on BBB To: Tim Kientzle , Ian Lepore , freebsd-arm Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Sep 2013 05:26:00 -0000 Hi, I found that issue. It is because I disabled this options: #options DDB #Enable the kernel debugger #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 DIAGNOSTIC Without them rootfs does not mount (kernel does not freeze, when I eject mmc, kernel shows "mmc0: detached") I use default kernel config and it works fine. Thanks, Yin On 15 September 2013 07:25, Tim Kientzle wrote: > > On Sep 14, 2013, at 12:55 PM, Ian Lepore wrote: > >> On Sun, 2013-09-15 at 01:15 +0800, Su Kang Yin wrote: >>> Log: >>> >>> 48.0MHz/4bit/65535-block >>> uhub0: 1 port with 1 removable, self powered >>> uhub1: 1 port with 1 removable, self powered >>> >>> ^^^^^^^^^^ Stuck here.... and I didn't connect any usb device. >>> >>> Any idea? >>> >> >> Two thoughts... make sure you're powering the board with a 5v adapter, >> not through a usb connection, > > I have lots of 5v supplies around but when I recently tried > to run one of my BBB from a USB connection, it did hang > a lot. The BBW worked okay, though. > > I suspect we're missing some boot code to detect > the power source and adjust the CPU clock accordingly. > >> and try adding this to your kernel config: >> >> option USB_HOST_ALIGN=64 >> >> If I don't use a separate power supply I get strange usb errors (but not >> a hang). If I do use the power supply, I get a data abort. Usb has >> never worked on my BBW, but I don't need it, so I've never tried hard to >> figure out why. > > I've just recently started tinkering with USB on my BBB here. > In particular, I've been able to run a urtwn USB Wifi adapter > (Specifically: adafru.it/814). > > I haven't tried with the BBW, though. > > Tim > > > _______________________________________________ > 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 Sun Sep 15 05:40:14 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 6C375635 for ; Sun, 15 Sep 2013 05:40:14 +0000 (UTC) (envelope-from paradyse@gmail.com) Received: from mail-wg0-x232.google.com (mail-wg0-x232.google.com [IPv6:2a00:1450:400c:c00::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 0C5F22F2E for ; Sun, 15 Sep 2013 05:40:13 +0000 (UTC) Received: by mail-wg0-f50.google.com with SMTP id f12so2549991wgh.5 for ; Sat, 14 Sep 2013 22:40:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=ukXpjOJu+f3uE9TA46Exni5/MxGmJIHV6YO3c1U6QaM=; b=ALkeayWo1WT5/hNCBvowywmJZhy5aZbxArv25zyu6QKbSTIl2hKvFmbqIj+n5GOXdy B8QQfYMWJo8LTo+Sq7vIKPw7+6vIWLvopjBVru1gUufVjZOQF+7689PVGwqC0r1bprIv GIb+Y63CjT83a26KMtqUQhKLzLYjcv93MDA1yPOQqL4f0E17KH367k7enovZ65D0Uf/l 0vRH+wmiT5f8OXrWhORJBTMffKiGnGHS3n1WUkqLJmp8zIIv6uG1nGDFBLSghlWZncjJ ej22Zyw8QD8yFR4vpKCy/TwgbhQ5nRnPTlDLQ6vg5F/GJe043KmeHp8mLPYHRJ8wvTWM 402A== X-Received: by 10.180.205.236 with SMTP id lj12mr8562008wic.22.1379223612268; Sat, 14 Sep 2013 22:40:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.134.170 with HTTP; Sat, 14 Sep 2013 22:39:42 -0700 (PDT) From: Su Kang Yin Date: Sun, 15 Sep 2013 13:39:42 +0800 Message-ID: Subject: sshd isnt working? To: freebsd-arm Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Sep 2013 05:40:14 -0000 Hi, sshd throwing signal 6 on server side messages log: Sep 15 05:32:31 beaglebone kernel: pid 896 (sshd), uid 22: exited on signal 6 On FreeBSD version: FreeBSD beaglebone 10.0-ALPHA1 FreeBSD 10.0-ALPHA1 #0 r255586: Sun Sep 15 12:53:16 HKT 2013 root@freebsd:/usr/home/cantona/crochet-freebsd/work/obj/arm.a rmv6/usr/src.head/sys/BEAGLEBONE arm On the source side of the ssh connection I get this error messages with verbose mode: OpenSSH_5.9p1, OpenSSL 0.9.8y 5 Feb 2013 debug1: Reading configuration data /etc/ssh_config debug1: /etc/ssh_config line 20: Applying options for * debug1: /etc/ssh_config line 53: Applying options for * debug1: Connecting to 192.168.2.2 [192.168.2.2] port 22. debug1: Connection established. debug1: identity file /Users/cantona/.ssh/id_rsa type 1 debug1: identity file /Users/cantona/.ssh/id_rsa-cert type -1 debug1: identity file /Users/cantona/.ssh/id_dsa type -1 debug1: identity file /Users/cantona/.ssh/id_dsa-cert type -1 debug1: Remote protocol version 2.0, remote software version OpenSSH_6.2_hpn13v11 FreeBSD-20130515 debug1: match: OpenSSH_6.2_hpn13v11 FreeBSD-20130515 pat OpenSSH* debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_5.9 debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug1: kex: server->client aes128-ctr hmac-md5 none debug1: kex: client->server aes128-ctr hmac-md5 none debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP debug1: SSH2_MSG_KEX_DH_GEX_INIT sent debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY Connection closed by 192.168.2.2 Anyone have an idea about this problem? Thanks, Yin From owner-freebsd-arm@FreeBSD.ORG Sun Sep 15 06:07:34 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 52FE6AC9 for ; Sun, 15 Sep 2013 06:07:34 +0000 (UTC) (envelope-from werner@makani-kai.com) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 1CA602006 for ; Sun, 15 Sep 2013 06:07:33 +0000 (UTC) Received: from agora.local (udp004035uds.hawaiiantel.net [72.234.77.213]) by mrelay.perfora.net (node=mrus3) with ESMTP (Nemesis) id 0MMTI6-1VIL853PJu-007zze; Sun, 15 Sep 2013 02:07:22 -0400 Message-ID: <52354E8F.1010808@makani-kai.com> Date: Sat, 14 Sep 2013 20:07:11 -1000 From: Werner Thie Organization: Makani Kai LLC User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Tim Kientzle Subject: crochet failing when installing ubldr Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V02:K0:05giZTZi+V9VgB8gb6szHSlbI0KqgO6pYsivJAt59Ca XufHQjMNVqjSl7Cb63/4EI13jp7XWuvp4i+RFDldBEz2pomGB7 MuCBKlG4vGtU+Tw/sudEyrAZWpZ9QWIODEWHSXrAt+mtwgsLrz ZEpqDDx8/lTlEY3fodvkFJ4cS1UrShLE3XAzhafV4CQThCbplQ yPwJprg4BNL9V93hrF3gODJjif5+h6yuljL9WHzOFq+vu+GXRH YPQcqmZs3pHQdJhG2F6RPU6YeUx3p8sL/Ajo3IsSMYP09bqYYW CE/pvNWEAdBWrwiXfprzku3zJqhXOgFp0Sn5E8PqncXXQ8rfBy yUaKNmUlapRl9Uyu+JCA= Cc: "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: werner@makani-kai.com List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Sep 2013 06:07:34 -0000 Hi Tim sorry for bugging you, but crochet is failing when installing ubldr sh /usr/local/src/tools/install.sh -o root -g wheel -m 444 /usr/local/src/sys/boot/arm/uboot/../../forth/loader.conf /home/wthie/proj/crochet-freebsd/work/ubldr-armv6-BEAGLEBONE-NOWITNESS//boot/defaults/loader.conf which seems very strange (path has a double // in front of boot). The file loader.conf is available and I'm scratching my head for the code which assembles this path Mahalo, Werner FreeBSD sources: svn info /usr/local/src Path: /usr/local/src Working Copy Root Path: /usr/local/src URL: http://svn.freebsd.org/base/head Relative URL: ^/head Repository Root: http://svn.freebsd.org/base Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f Revision: 255586 Node Kind: directory Schedule: normal Last Changed Author: des Last Changed Rev: 255586 Last Changed Date: 2013-09-15 03:44:07 +0200 (Sun, 15 Sep 2013) System uname -a FreeBSD xtools 9.1-RELEASE-p3 FreeBSD 9.1-RELEASE-p3 #0: Mon Apr 29 18:11:52 UTC 2013 root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC i386 Ports upgraded today From owner-freebsd-arm@FreeBSD.ORG Sun Sep 15 06:27:41 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 67831D60 for ; Sun, 15 Sep 2013 06:27:41 +0000 (UTC) (envelope-from paradyse@gmail.com) Received: from mail-wi0-x232.google.com (mail-wi0-x232.google.com [IPv6:2a00:1450:400c:c05::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 0748920DF for ; Sun, 15 Sep 2013 06:27:40 +0000 (UTC) Received: by mail-wi0-f178.google.com with SMTP id hn9so2267005wib.17 for ; Sat, 14 Sep 2013 23:27:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=MiobucnmsmLvfNP71TD21EHBP7d7y2bAi6t5ktKLmhI=; b=D1Z7C/v9l0XyMu0ilHXJsGDq91/k5jfGSZT0pKMCFbBoPT83r6xSKbsozqMl9O/uil anDTxSguWEKUZWMs4yDl2Rgg5unG6T52pnaKuI6ocdvBf1zAT3tizz6WGqcyfMHgL6fS rF/VSA3O2hz9V7S/lCzXilVPADLVIw0Yry2Z0tt0fMiPph+W7Xz8bH6v/aYX6hVsLra4 8W/laC42DHtgUQC5D5ZMO7dwGF/LXCMdF2nfS+6PeB0rDdKzt6qRQnBK7pcVE+UmvaMC fCb0u+YOFl+HwQfRBJD7MDV+TrJ6cLWKq5hLHf95T7zcaWPvO3OCdrxd0RiKPfk9o0Vy AJzA== X-Received: by 10.180.205.236 with SMTP id lj12mr8670277wic.22.1379226459328; Sat, 14 Sep 2013 23:27:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.134.170 with HTTP; Sat, 14 Sep 2013 23:27:09 -0700 (PDT) In-Reply-To: References: From: Su Kang Yin Date: Sun, 15 Sep 2013 14:27:09 +0800 Message-ID: Subject: Re: sshd isnt working? To: freebsd-arm Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Sep 2013 06:27:41 -0000 Its totally wierd. Adding "UsePrivilegeSeparation no" in sshd_config work-around it. On 15 September 2013 13:39, Su Kang Yin wrote: > Hi, > > sshd throwing signal 6 on server side > > messages log: > Sep 15 05:32:31 beaglebone kernel: pid 896 (sshd), uid 22: exited on signal 6 > > On FreeBSD version: > FreeBSD beaglebone 10.0-ALPHA1 FreeBSD 10.0-ALPHA1 #0 r255586: Sun Sep > 15 12:53:16 HKT 2013 > root@freebsd:/usr/home/cantona/crochet-freebsd/work/obj/arm.a > rmv6/usr/src.head/sys/BEAGLEBONE arm > > > On the source side of the ssh connection I get this error messages > with verbose mode: > OpenSSH_5.9p1, OpenSSL 0.9.8y 5 Feb 2013 > debug1: Reading configuration data /etc/ssh_config > debug1: /etc/ssh_config line 20: Applying options for * > debug1: /etc/ssh_config line 53: Applying options for * > debug1: Connecting to 192.168.2.2 [192.168.2.2] port 22. > debug1: Connection established. > debug1: identity file /Users/cantona/.ssh/id_rsa type 1 > debug1: identity file /Users/cantona/.ssh/id_rsa-cert type -1 > debug1: identity file /Users/cantona/.ssh/id_dsa type -1 > debug1: identity file /Users/cantona/.ssh/id_dsa-cert type -1 > debug1: Remote protocol version 2.0, remote software version > OpenSSH_6.2_hpn13v11 FreeBSD-20130515 > debug1: match: OpenSSH_6.2_hpn13v11 FreeBSD-20130515 pat OpenSSH* > debug1: Enabling compatibility mode for protocol 2.0 > debug1: Local version string SSH-2.0-OpenSSH_5.9 > debug1: SSH2_MSG_KEXINIT sent > debug1: SSH2_MSG_KEXINIT received > debug1: kex: server->client aes128-ctr hmac-md5 none > debug1: kex: client->server aes128-ctr hmac-md5 none > debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent > debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP > debug1: SSH2_MSG_KEX_DH_GEX_INIT sent > debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY > Connection closed by 192.168.2.2 > > Anyone have an idea about this problem? > > Thanks, > Yin From owner-freebsd-arm@FreeBSD.ORG Sun Sep 15 12:00:28 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 97ADE173 for ; Sun, 15 Sep 2013 12:00:28 +0000 (UTC) (envelope-from db@db.net) Received: from diana.db.net (diana.db.net [66.113.102.10]) by mx1.freebsd.org (Postfix) with ESMTP id 81B0D2D92 for ; Sun, 15 Sep 2013 12:00:28 +0000 (UTC) Received: from night.db.net (localhost [127.0.0.1]) by diana.db.net (Postfix) with ESMTP id 06CAF2AA4F2; Sun, 15 Sep 2013 06:00:22 -0600 (MDT) Received: by night.db.net (Postfix, from userid 1000) id F22651CC20; Sun, 15 Sep 2013 07:00:05 -0500 (EST) Date: Sun, 15 Sep 2013 07:00:05 -0500 From: Diane Bruce To: Su Kang Yin Subject: Re: sshd isnt working? Message-ID: <20130915120005.GA16617@night.db.net> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Sep 2013 12:00:28 -0000 On Sun, Sep 15, 2013 at 01:39:42PM +0800, Su Kang Yin wrote: > Hi, > > sshd throwing signal 6 on server side > > messages log: > Sep 15 05:32:31 beaglebone kernel: pid 896 (sshd), uid 22: exited on signal 6 > > On FreeBSD version: > FreeBSD beaglebone 10.0-ALPHA1 FreeBSD 10.0-ALPHA1 #0 r255586: Sun Sep > 15 12:53:16 HKT 2013 > root@freebsd:/usr/home/cantona/crochet-freebsd/work/obj/arm.a > rmv6/usr/src.head/sys/BEAGLEBONE arm > ... > > Anyone have an idea about this problem? Yes. http://docs.freebsd.org/cgi/getmsg.cgi?fetch=199241+0+archive/2013/freebsd-arm/20130728.freebsd-arm I see you rediscovered this as well. I did poke at it a bit more and found http://docs.freebsd.org/cgi/getmsg.cgi?fetch=47500+0+archive/2013/freebsd-arm/20130825.freebsd-arm zbb and Matthias Meyser reported another weird jemalloc error which is in PR 182060 http://www.freebsd.org/cgi/query-pr.cgi?pr=182060&cat= I believe this is the exact same problem manifesting itself elsewhere. I suspect we have a locking problem in the mutex code used on armv6. > Thanks, > Yin - Diane -- - db@FreeBSD.org db@db.net http://www.db.net/~db From owner-freebsd-arm@FreeBSD.ORG Sun Sep 15 13:07:05 2013 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id DEC5C7CA for ; Sun, 15 Sep 2013 13:07:05 +0000 (UTC) (envelope-from ian@FreeBSD.org) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id B400A20C4 for ; Sun, 15 Sep 2013 13:07:04 +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 1VLC2Z-000M8O-OE; Sun, 15 Sep 2013 13:07:03 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id r8FD6xwq011697; Sun, 15 Sep 2013 07:06:59 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+9RwU5H+ugcLy8aRl9mBlb Subject: Re: crochet failing when installing ubldr From: Ian Lepore To: werner@makani-kai.com In-Reply-To: <52354E8F.1010808@makani-kai.com> References: <52354E8F.1010808@makani-kai.com> Content-Type: text/plain; charset="us-ascii" Date: Sun, 15 Sep 2013 07:06:59 -0600 Message-ID: <1379250419.1197.43.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: Tim Kientzle , "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Sep 2013 13:07:05 -0000 On Sat, 2013-09-14 at 20:07 -1000, Werner Thie wrote: > Hi Tim > > sorry for bugging you, but crochet is failing when installing ubldr > > sh /usr/local/src/tools/install.sh -o root -g wheel -m 444 > /usr/local/src/sys/boot/arm/uboot/../../forth/loader.conf > /home/wthie/proj/crochet-freebsd/work/ubldr-armv6-BEAGLEBONE-NOWITNESS//boot/defaults/loader.conf > > which seems very strange (path has a double // in front of boot). > > The file loader.conf is available and I'm scratching my head for the > code which assembles this path > > Mahalo, Werner > > [other info snipped] You don't show an actual error message there. The double slash is harmless, it happens sometimes when scripts concatenate configured path strings together. -- Ian From owner-freebsd-arm@FreeBSD.ORG Sun Sep 15 13:32:02 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 984B2CEA for ; Sun, 15 Sep 2013 13:32:02 +0000 (UTC) (envelope-from ronald-freebsd8@klop.yi.org) Received: from cpsmtpb-ews04.kpnxchange.com (cpsmtpb-ews04.kpnxchange.com [213.75.39.7]) by mx1.freebsd.org (Postfix) with ESMTP id 046B421E3 for ; Sun, 15 Sep 2013 13:32:01 +0000 (UTC) Received: from cpsps-ews30.kpnxchange.com ([10.94.84.196]) by cpsmtpb-ews04.kpnxchange.com with Microsoft SMTPSVC(7.5.7601.17514); Sun, 15 Sep 2013 15:31:51 +0200 Received: from CPSMTPM-TLF102.kpnxchange.com ([195.121.3.5]) by cpsps-ews30.kpnxchange.com with Microsoft SMTPSVC(7.5.7601.17514); Sun, 15 Sep 2013 15:31:51 +0200 Received: from sjakie.klop.ws ([212.182.167.131]) by CPSMTPM-TLF102.kpnxchange.com with Microsoft SMTPSVC(7.5.7601.17514); Sun, 15 Sep 2013 15:31:51 +0200 Received: from 212-182-167-131.ip.telfort.nl (localhost [127.0.0.1]) by sjakie.klop.ws (Postfix) with ESMTP id A19EF16B53 for ; Sun, 15 Sep 2013 15:31:50 +0200 (CEST) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes To: freebsd-arm@freebsd.org Subject: Re: Panic while building perl on sheevaplug/armv5 freebsd 10. References: <1379080987.1111.637.camel@revolution.hippie.lan> Date: Sun, 15 Sep 2013 15:31:50 +0200 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Ronald Klop" Message-ID: In-Reply-To: <1379080987.1111.637.camel@revolution.hippie.lan> User-Agent: Opera Mail/12.16 (FreeBSD) X-OriginalArrivalTime: 15 Sep 2013 13:31:51.0541 (UTC) FILETIME=[EFAD0A50:01CEB217] X-RcptDomain: freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Sep 2013 13:32:02 -0000 On Fri, 13 Sep 2013 16:03:07 +0200, Ian Lepore wrote: > On Fri, 2013-09-13 at 15:11 +0200, Ronald Klop wrote: >> Hello, >> >> I have a repeatable panic while building perl on my Sheevaplug ARMv5 >> running FreeBSD 10-CURRENT. >> Kernel is loaded from NAND. >> / is mounted from USB /dev/da0s2 (UFS2) >> /usr/ports is mounted over NFS from a 9-STABLE/amd64 box. >> Swap from 512MB file in /data/swap. >> >> ---- console output >> login: panic: vm_fault: fault on nofault entry, addr: ddf9d000 >> KDB: enter: panic >> [ thread pid 659 tid 100057 ] >> Stopped at kdb_enter+0x4c: ldrb r15, [r15, r15, ror r15]! >> db> bt >> Tracing pid 659 tid 100057 td 0xc3f86000 > [...] >> exception_exit() at exception_exit >> pc = 0xc0bba3fc lr = 0xc0a60c88 (tc_setclock+0x458) >> sp = 0xddf9d008 fp = 0xddf9e038 >> r0 = 0xc0bba324 r1 = 0xc0d00000 >> r2 = 0xddf9d00c r3 = 0x20000093 >> r4 = 0x00000000 r5 = 0xc0ccd630 >> r6 = 0x00000000 r7 = 0x00000000 >> r8 = 0xc0caece0 r9 = 0x00000001 >> r10 = 0xc0caec88 r12 = 0x00000000 >> data_abort_entry() at data_abort_entry+0x30 >> pc = 0xc0bba324 lr = 0xc0a60c88 (tc_setclock+0x458) >> sp = 0xddf9d008 fp = 0xddf9e038 >> Unwind failure (no registers changed) > > That's the second time in the past few months I've seen a backtrace that > makes it look like we ran out of kernel stack, but the default is 8k > which should be plenty. Still, try adding "option KSTACK_PAGES=3" to > your kernel config and see if the problem goes away. If it does, we may > need to figure out why we're using so much stack. If it doesn't, we've > probably got a bad recursion loop happening somewhere. > > -- Ian > I had to bump KSTACK_PAGES up to 4, but now it is going on with building ports. Ronald. From owner-freebsd-arm@FreeBSD.ORG Sun Sep 15 14:15:06 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 8BEEC75C; Sun, 15 Sep 2013 14:15:06 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from smtpauth4.wiscmail.wisc.edu (wmauth4.doit.wisc.edu [144.92.197.145]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 5C75F23AF; Sun, 15 Sep 2013 14:15:05 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII; format=flowed Received: from avs-daemon.smtpauth4.wiscmail.wisc.edu by smtpauth4.wiscmail.wisc.edu (Oracle Communications Messaging Server 7u4-27.01(7.0.4.27.0) 64bit (built Aug 30 2012)) id <0MT6005006N9HK00@smtpauth4.wiscmail.wisc.edu>; Sun, 15 Sep 2013 09:14:59 -0500 (CDT) X-Spam-PmxInfo: Server=avs-4, Version=6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2013.9.15.140615, SenderIP=0.0.0.0 X-Spam-Report: AuthenticatedSender=yes, SenderIP=0.0.0.0 Received: from comporellon.tachypleus.net (unknown [76.210.60.217]) by smtpauth4.wiscmail.wisc.edu (Oracle Communications Messaging Server 7u4-27.01(7.0.4.27.0) 64bit (built Aug 30 2012)) with ESMTPSA id <0MT6004HH7KXYU00@smtpauth4.wiscmail.wisc.edu>; Sun, 15 Sep 2013 09:14:59 -0500 (CDT) Message-id: <5235C0E1.9080009@freebsd.org> Date: Sun, 15 Sep 2013 09:14:57 -0500 From: Nathan Whitehorn User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130907 Thunderbird/17.0.8 To: Eitan Adler Subject: Re: Patch for Cross-Reference Phandles References: <522CC7E0.9060508@freebsd.org> <5231D8A6.9080501@freebsd.org> <20130914133155.GA32845@alchemy.franken.de> <52346D71.4080407@freebsd.org> <1379173405.1197.7.camel@revolution.hippie.lan> <20130914172735.GX68682@funkthat.com> <1379181341.1197.26.camel@revolution.hippie.lan> In-reply-to: Cc: Ian Lepore , "freebsd-arm@freebsd.org" , freebsd-sparc64 , FreeBSD PowerPC ML X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Sep 2013 14:15:06 -0000 On 09/14/13 19:04, Eitan Adler wrote: > [ *please* bottom post ] > > On Sat, Sep 14, 2013 at 7:56 PM, Adrian Chadd wrote: >> ... holy crap. :-) >> >> erm, try writing some code that does something with it: >> >> int foo[2] = { 0, 0 }; >> >> main() >> { >> int i; >> for (i = 0; i < 2; i++) { >> foo[i] = i; >> } >> } >> >> .. and then make foo[2] be foo[512] and explicitly set it up to be zero'ed. >> see what happens. > With an explicit zeroing: > > text data bss dec hex filename > 1572 484 16 2072 818 a.out > > Without: > > text data bss dec hex filename > 1572 484 16 2072 818 a.out > _______________________________________________ > freebsd-ppc@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ppc > To unsubscribe, send any mail to "freebsd-ppc-unsubscribe@freebsd.org" There's an explanation of this behavior attached to the -fno-zero-initialized-in-bss argument to GCC. I've pasted the relevant section of the man page below: -fno-zero-initialized-in-bss If the target supports a BSS section, GCC by default puts variables that are initialized to zero into BSS. This can save space in the resulting code. This option turns off this behavior because some programs explic- itly rely on variables going to the data section. E.g., so that the resulting executable can find the beginning of that section and/or make assumptions based on that. The default is -fzero-initialized-in-bss. This is why I wasn't worried about the = 0... -Nathan From owner-freebsd-arm@FreeBSD.ORG Sun Sep 15 14:33:10 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id CC679CC3 for ; Sun, 15 Sep 2013 14:33:10 +0000 (UTC) (envelope-from pmather@vt.edu) Received: from lennier.cc.vt.edu (lennier.cc.vt.edu [198.82.162.213]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 7E62D24A9 for ; Sun, 15 Sep 2013 14:33:10 +0000 (UTC) Received: from mr2.cc.vt.edu (mr2.cc.vt.edu [198.82.163.74]) by lennier.cc.vt.edu (8.13.8/8.13.8) with ESMTP id r8FEWd6a014371 for ; Sun, 15 Sep 2013 10:32:39 -0400 Received: from mail-qc0-f180.google.com (mail-qc0-f180.google.com [209.85.216.180]) by mr2.cc.vt.edu (8.14.4/8.14.4) with ESMTP id r8FEWd6X019088 for ; Sun, 15 Sep 2013 10:32:39 -0400 Received: by mail-qc0-f180.google.com with SMTP id p19so2167211qcv.11 for ; Sun, 15 Sep 2013 07:32:39 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=lUEZu1/xq5bx6HeEmDLWiYVx/pkbXCW5hUoU7Ip46Xo=; b=M+2fspVPjNvHFtHLqK5yazuMh+qMlFTog5MpkjNSJu2s6QjDcbapf8rqFVT9uffxsF YvJ7rd5SPkbcO/BUSJgvFP2fL2KjyBj4QyNye7+DWt6PEp7z8UfKbZpmK1BSN2VgqWoK gVQlCKjE4Ww1gGDmvWwkfyCegWnWsMURxWgT+yMYpLiRiIN6fTdlHtcWcIY1eoMEpJ1L 28EyGRz5zdKcbd/oB2hDsDSoP3ZoEudXMOL3ee1JFE9akgw26ugo6WQCn/GHkYrlFcaH b/yZS0hGfTNKa9GAyoC2qsCQdeMK46kiIHf1aGVEPd468eCno1e+UltfsSfLEPMrVFZ4 dGlw== X-Gm-Message-State: ALoCoQkZPi8cv5Y62iJYKfuKKLEHJScRfCZnpor54jl+KJytimZdSqvnCsqwkM6oEzLHJzwYz3RCGsin2v8/ZucD7CMHmXrzY3/bTxtCDckZsDEW++6ot07KYNRsDKDXft41w2+a9xWK5Ey2HewdTpRo4hG1IQoEE+bZ6+m2mTkc96xb4T7bnEA= X-Received: by 10.229.73.6 with SMTP id o6mr40665540qcj.2.1379255559196; Sun, 15 Sep 2013 07:32:39 -0700 (PDT) X-Received: by 10.229.73.6 with SMTP id o6mr40665527qcj.2.1379255559104; Sun, 15 Sep 2013 07:32:39 -0700 (PDT) Received: from macbook.chumby.lan (c-98-249-9-133.hsd1.va.comcast.net. [98.249.9.133]) by mx.google.com with ESMTPSA id fy7sm39222429qeb.1.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 15 Sep 2013 07:32:38 -0700 (PDT) Subject: Re: FreeBSD 10.0-ALPHA1 r255532 bootup freeze on BBB Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Paul Mather In-Reply-To: Date: Sun, 15 Sep 2013 10:32:37 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1379188513.1197.35.camel@revolution.hippie.lan> <0AC11ABC-5C40-4C63-B90D-2E686562BFD2@kientzle.com> To: Su Kang Yin X-Mailer: Apple Mail (2.1283) Cc: Tim Kientzle , freebsd-arm , Ian Lepore X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Sep 2013 14:33:10 -0000 On Sep 15, 2013, at 1:25 AM, Su Kang Yin wrote: > Hi, >=20 > I found that issue. >=20 > It is because I disabled this options: >=20 > #options DDB #Enable the kernel debugger > #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 DIAGNOSTIC >=20 > Without them rootfs does not mount (kernel does not freeze, when I > eject mmc, kernel shows "mmc0: detached") >=20 >=20 > I use default kernel config and it works fine. I can report that this also happened to me on BeagleBone Black with = those debugging options removed. The kernel would boot but would then = stop when trying to mount the root file system. Oddly enough, a kernel of the same revision (r255420) with those = debugging options removed will boot to multi-user on Raspberry Pi. Cheers, Paul. >=20 > Thanks, > Yin >=20 > On 15 September 2013 07:25, Tim Kientzle wrote: >>=20 >> On Sep 14, 2013, at 12:55 PM, Ian Lepore wrote: >>=20 >>> On Sun, 2013-09-15 at 01:15 +0800, Su Kang Yin wrote: >>>> Log: >>>>=20 >>>> 48.0MHz/4bit/65535-block >>>> uhub0: 1 port with 1 removable, self powered >>>> uhub1: 1 port with 1 removable, self powered >>>>=20 >>>> ^^^^^^^^^^ Stuck here.... and I didn't connect any usb device. >>>>=20 >>>> Any idea? >>>>=20 >>>=20 >>> Two thoughts... make sure you're powering the board with a 5v = adapter, >>> not through a usb connection, >>=20 >> I have lots of 5v supplies around but when I recently tried >> to run one of my BBB from a USB connection, it did hang >> a lot. The BBW worked okay, though. >>=20 >> I suspect we're missing some boot code to detect >> the power source and adjust the CPU clock accordingly. >>=20 >>> and try adding this to your kernel config: >>>=20 >>> option USB_HOST_ALIGN=3D64 >>>=20 >>> If I don't use a separate power supply I get strange usb errors (but = not >>> a hang). If I do use the power supply, I get a data abort. Usb has >>> never worked on my BBW, but I don't need it, so I've never tried = hard to >>> figure out why. >>=20 >> I've just recently started tinkering with USB on my BBB here. >> In particular, I've been able to run a urtwn USB Wifi adapter >> (Specifically: adafru.it/814). >>=20 >> I haven't tried with the BBW, though. >>=20 >> Tim >>=20 >>=20 >> _______________________________________________ >> 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" >=20 From owner-freebsd-arm@FreeBSD.ORG Sun Sep 15 14:52:56 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id E6C98F19 for ; Sun, 15 Sep 2013 14:52:56 +0000 (UTC) (envelope-from db@db.net) Received: from diana.db.net (unknown [IPv6:2620:64:0:1:223:7dff:fea2:c8f2]) by mx1.freebsd.org (Postfix) with ESMTP id CE26F255F for ; Sun, 15 Sep 2013 14:52:56 +0000 (UTC) Received: from night.db.net (localhost [127.0.0.1]) by diana.db.net (Postfix) with ESMTP id 65F1D2AA56C; Sun, 15 Sep 2013 08:52:54 -0600 (MDT) Received: by night.db.net (Postfix, from userid 1000) id 5D3791CC20; Sun, 15 Sep 2013 09:52:38 -0500 (EST) Date: Sun, 15 Sep 2013 09:52:38 -0500 From: Diane Bruce To: Paul Mather Subject: Re: sshd isnt working? Message-ID: <20130915145238.GB18382@night.db.net> References: <20130915120005.GA16617@night.db.net> <92A05C0F-B921-4998-8AF5-E0B4994E37D5@g.mail.vt.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <92A05C0F-B921-4998-8AF5-E0B4994E37D5@g.mail.vt.edu> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Sep 2013 14:52:57 -0000 On Sun, Sep 15, 2013 at 10:23:08AM -0400, Paul Mather wrote: > On Sep 15, 2013, at 8:00 AM, Diane Bruce wrote: > > > On Sun, Sep 15, 2013 at 01:39:42PM +0800, Su Kang Yin wrote: > >> Hi, > >> > >> sshd throwing signal 6 on server side ... > > > For me, I've only encountered this problem when connecting from certain clients---Mac OS X 10.7 and 10.8 so far. I can SSH to my Raspberry Pi and BeagleBone Black just fine from another RELENG_9 FreeBSD system, and from a Debian Wheezy system. The failure mode for those that don't work is the same as reported above---a signal 6 on the server side. Also, this hasn't always been the case, but I can't recall a revision number when the problem began. Yes, I have been trying to keep track of these types of reports as well. This strongly smells of a timing related problem. I have a ktrace of the entire process of sshd doing its thing. It would depend on how fast the connection was when it was hit. I initially thought we had a possible use after free so sent the ktrace to jasone@ . The problem goes away using ElectricFence from ports to replace the malloc code in sshd. Using jemalloc's opt.quarantine feature, the problem will also go away. I think this the commit that triggered this bug. http://svnweb.freebsd.org/base?view=revision&revision=250991 I'd be curious if quarantine use results in a successful world build, but it is quite memory intensive using quarantine. The asm code that does our atomic operations for arm6 must be reviewed. As sshd uses pthreads, jemalloc utilises pthread_mutex calls. > > Cheers, > > Paul. > > Diane -- - db@FreeBSD.org db@db.net http://www.db.net/~db From owner-freebsd-arm@FreeBSD.ORG Sun Sep 15 15:28:16 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id E0DD6974 for ; Sun, 15 Sep 2013 15:28:16 +0000 (UTC) (envelope-from george+freebsd@m5p.com) Received: from mailhost.m5p.com (ip-2-1-0-2.r03.asbnva02.us.ce.gin.ntt.net [IPv6:2001:418:0:5000::16]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 7E06F2720 for ; Sun, 15 Sep 2013 15:28:16 +0000 (UTC) Received: from wonderland.m5p.com (localhost [IPv6:::1]) by mailhost.m5p.com (8.14.5/8.14.5) with ESMTP id r8FFS7TX008246 for ; Sun, 15 Sep 2013 11:28:13 -0400 (EDT) (envelope-from george+freebsd@m5p.com) Message-ID: <5235D207.5070400@m5p.com> Date: Sun, 15 Sep 2013 11:28:07 -0400 From: George Mitchell User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130716 Thunderbird/17.0.7 MIME-Version: 1.0 To: "freebsd-arm@freebsd.org" Subject: Re: What's the recipe? References: <522229C0.5030504@m5p.com> In-Reply-To: <522229C0.5030504@m5p.com> Content-Type: multipart/mixed; boundary="------------000600030505060805040308" X-Scanned-By: MIMEDefang 2.73 on 10.100.0.3 X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.7 (mailhost.m5p.com [IPv6:::1]); Sun, 15 Sep 2013 11:28:15 -0400 (EDT) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Sep 2013 15:28:16 -0000 This is a multi-part message in MIME format. --------------000600030505060805040308 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 08/31/13 13:37, George Mitchell wrote: > Have you built a working Raspberry Pi image recently? If so, for the > benefit of the rest of us, could you share a few secrets? > > 1. What system did you do the build on? If it was an i386 or amd64, > what svn version was it built with? Built on amd64, svn version r255361M. (Two changes: I still distrust SCHED_ULE, and there's a patch [attached] required for the ARM xdev build to complete.) > > 2. What did you have in /etc/src.conf and /etc/make.conf, both for > building the build system itself and for building the RPi? I finally bit the bullet and went to clang. /etc/src.conf is empty; /etc/make.conf contains "WITH_PKGNG=yes". > > 3. What svn version of /usr/src did you use in building the RPi image? > Same as above (r255361M). > 4. Did you use crochet? If so, what was the last commit in your git > log? commit b154a2f1252eaa5f4d821439d0d9005cea94e580 Merge: a6f4cc5 8d03c23 Author: Tim Kientzle Date: Sat Aug 17 12:00:52 2013 -0700 > > When I say "working," I'm hoping for the ability to run stably for a > number of days, running NFS and CUPS. I've been doing this since > January with a precompiled image I downloaded then which worked > wonderfully with one of my printers, but not the other one. Now > there's a patch that enables both printers to work, and I would love > to build a new image. So I've been thrashing around trying to find > the answers to the questions above without success. Thanks for any > help you can give! -- George This build is marginally stable. I've been working for a week to get a complete build of print/cups and I'm not quite there. From the RPi, /usr/ports is an NFS mount from another machine with version 326306 of the ports tree (just before the iconv incident). The RPi likes to get messages of this sort: http://www.m5p.com/~george/pi/DSCN1282.JPG primarily during the period that portmaster is discovering everybody's dependencies. (Oddly, if I make it to the build stage, the build completes about 90% of the time. devel/glib20 built, including its dependencies on perl and python, in one overnight session.) Once, instead of the fatal kernel mode prefetch abort, I got: panic: __rw_wlock_hard: recursing but non-recursive rw pmap pw @ /usr/src/sys/arm/arm/pmap-v6.c:1406 KDB: enter: panic [ thread pid 906 tid 100076 ] stopped at $d: ldrb r15, [r15, 15, ror r15] (Sorry for the transcription by hand; I have an AdaFruit serial cable on order.) My current problem is that x11/pixman fails to build: ===> Building for pixman-0.30.0 /usr/bin/make all-recursive Making all in pixman CC pixman.lo CC pixman-access.lo CC pixman-access-accessors.lo CC pixman-bits-image.lo CC pixman-combine32.lo CC pixman-combine-float.lo CC pixman-conical-gradient.lo CC pixman-filter.lo CC pixman-x86.lo CC pixman-mips.lo CC pixman-arm.lo CC pixman-ppc.lo CC pixman-edge.lo CC pixman-edge-accessors.lo CC pixman-fast-path.lo CC pixman-glyph.lo CC pixman-general.lo CC pixman-gradient-walker.lo CC pixman-image.lo CC pixman-implementation.lo pixman-implementation.c:124:38: warning: comparison of constant 64 with expression of type 'const pixman_op_t' is always false [-Wtautological-constant-out-of-range-compare] if ((info->op == op || info->op == PIXMAN_OP_any) && ~~~~~~~~ ^ ~~~~~~~~~~~~~ 1 warning generated. CC pixman-linear-gradient.lo CC pixman-matrix.lo CC pixman-noop.lo CC pixman-radial-gradient.lo CC pixman-region16.lo CC pixman-region32.lo CC pixman-solid-fill.lo CC pixman-timer.lo CC pixman-trap.lo CC pixman-utils.lo CC pixman-arm-neon.lo CPPAS pixman-arm-neon-asm.lo /usr/include/float.h: Assembler messages: /usr/include/float.h:43: Error: bad instruction `extern int __flt_rounds(void)' ./pixman-arm-neon-asm.h:947: Warning: ignoring redefinition of register alias 'dst_w' ./pixman-arm-neon-asm.h:947: Warning: ignoring redefinition of register alias 'src' ./pixman-arm-neon-asm.h:947: Warning: ignoring redefinition of register alias 'dst_r' ./pixman-arm-neon-asm.h:947: Warning: ignoring redefinition of register alias 'mask' ./pixman-arm-neon-asm.h:947: Warning: ignoring redefinition of register alias 'dst_w' ./pixman-arm-neon-asm.h:947: Warning: ignoring redefinition of register alias 'src' ./pixman-arm-neon-asm.h:947: Warning: ignoring redefinition of register alias 'dst_r' ./pixman-arm-neon-asm.h:947: Warning: ignoring redefinition of register alias 'mask' ./pixman-arm-neon-asm.h:947: Warning: ignoring redefinition of register alias 'dst_w' ./pixman-arm-neon-asm.h:947: Warning: ignoring redefinition of register alias 'src' ./pixman-arm-neon-asm.h:947: Warning: ignoring redefinition of register alias 'dst_r' ./pixman-arm-neon-asm.h:947: Warning: ignoring redefinition of register alias 'mask' ./pixman-arm-neon-asm.h:708: Warning: ignoring redefinition of register alias 'orig_w' ./pixman-arm-neon-asm.h:708: Warning: ignoring redefinition of register alias 'dummy' ./pixman-arm-neon-asm.h:708: Warning: ignoring redefinition of register alias 'orig_w' ./pixman-arm-neon-asm.h:708: Warning: ignoring redefinition of register alias 'dummy' ./pixman-arm-neon-asm.h:708: Warning: ignoring redefinition of register alias 'orig_w' ./pixman-arm-neon-asm.h:708: Warning: ignoring redefinition of register alias 'dummy' ./pixman-arm-neon-asm.h:708: Warning: ignoring redefinition of register alias 'orig_w' ./pixman-arm-neon-asm.h:708: Warning: ignoring redefinition of register alias 'dummy' ./pixman-arm-neon-asm.h:708: Warning: ignoring redefinition of register alias 'orig_w' ./pixman-arm-neon-asm.h:708: Warning: ignoring redefinition of register alias 'dummy' ./pixman-arm-neon-asm.h:708: Warning: ignoring redefinition of register alias 'orig_w' ./pixman-arm-neon-asm.h:708: Warning: ignoring redefinition of register alias 'dummy' ./pixman-arm-neon-asm.h:708: Warning: ignoring redefinition of register alias 'orig_w' ./pixman-arm-neon-asm.h:708: Warning: ignoring redefinition of register alias 'dummy' ./pixman-arm-neon-asm.h:708: Warning: ignoring redefinition of register alias 'orig_w' ./pixman-arm-neon-asm.h:708: Warning: ignoring redefinition of register alias 'dummy' ./pixman-arm-neon-asm.h:708: Warning: ignoring redefinition of register alias 'orig_w' ./pixman-arm-neon-asm.h:708: Warning: ignoring redefinition of register alias 'dummy' ./pixman-arm-neon-asm.h:708: Warning: ignoring redefinition of register alias 'orig_w' ./pixman-arm-neon-asm.h:708: Warning: ignoring redefinition of register alias 'dummy' ./pixman-arm-neon-asm.h:708: Warning: ignoring redefinition of register alias 'orig_w' ./pixman-arm-neon-asm.h:708: Warning: ignoring redefinition of register alias 'dummy' ./pixman-arm-neon-asm.h:708: Warning: ignoring redefinition of register alias 'orig_w' ./pixman-arm-neon-asm.h:708: Warning: ignoring redefinition of register alias 'dummy' ./pixman-arm-neon-asm.h:708: Warning: ignoring redefinition of register alias 'orig_w' ./pixman-arm-neon-asm.h:708: Warning: ignoring redefinition of register alias 'dummy' ./pixman-arm-neon-asm.h:708: Warning: ignoring redefinition of register alias 'orig_w' ./pixman-arm-neon-asm.h:708: Warning: ignoring redefinition of register alias 'dummy' ./pixman-arm-neon-asm.h:947: Warning: ignoring redefinition of register alias 'dst_w' ./pixman-arm-neon-asm.h:947: Warning: ignoring redefinition of register alias 'src' ./pixman-arm-neon-asm.h:947: Warning: ignoring redefinition of register alias 'dst_r' ./pixman-arm-neon-asm.h:947: Warning: ignoring redefinition of register alias 'mask' ./pixman-arm-neon-asm.h:708: Warning: ignoring redefinition of register alias 'orig_w' ./pixman-arm-neon-asm.h:708: Warning: ignoring redefinition of register alias 'dummy' ./pixman-arm-neon-asm.h:708: Warning: ignoring redefinition of register alias 'orig_w' ./pixman-arm-neon-asm.h:708: Warning: ignoring redefinition of register alias 'dummy' ./pixman-arm-neon-asm.h:947: Warning: ignoring redefinition of register alias 'dst_w' ./pixman-arm-neon-asm.h:947: Warning: ignoring redefinition of register alias 'src' ./pixman-arm-neon-asm.h:947: Warning: ignoring redefinition of register alias 'dst_r' ./pixman-arm-neon-asm.h:947: Warning: ignoring redefinition of register alias 'mask' ./pixman-arm-neon-asm.h:708: Warning: ignoring redefinition of register alias 'orig_w' ./pixman-arm-neon-asm.h:708: Warning: ignoring redefinition of register alias 'dummy' ./pixman-arm-neon-asm.h:947: Warning: ignoring redefinition of register alias 'dst_w' ./pixman-arm-neon-asm.h:947: Warning: ignoring redefinition of register alias 'src' ./pixman-arm-neon-asm.h:947: Warning: ignoring redefinition of register alias 'dst_r' ./pixman-arm-neon-asm.h:947: Warning: ignoring redefinition of register alias 'mask' ./pixman-arm-neon-asm.h:708: Warning: ignoring redefinition of register alias 'orig_w' ./pixman-arm-neon-asm.h:708: Warning: ignoring redefinition of register alias 'dummy' ./pixman-arm-neon-asm.h:708: Warning: ignoring redefinition of register alias 'orig_w' ./pixman-arm-neon-asm.h:708: Warning: ignoring redefinition of register alias 'dummy' ./pixman-arm-neon-asm.h:708: Warning: ignoring redefinition of register alias 'orig_w' ./pixman-arm-neon-asm.h:708: Warning: ignoring redefinition of register alias 'dummy' ./pixman-arm-neon-asm.h:708: Warning: ignoring redefinition of register alias 'orig_w' ./pixman-arm-neon-asm.h:708: Warning: ignoring redefinition of register alias 'dummy' ./pixman-arm-neon-asm.h:708: Warning: ignoring redefinition of register alias 'orig_w' ./pixman-arm-neon-asm.h:708: Warning: ignoring redefinition of register alias 'dummy' ./pixman-arm-neon-asm.h:708: Warning: ignoring redefinition of register alias 'orig_w' ./pixman-arm-neon-asm.h:708: Warning: ignoring redefinition of register alias 'dummy' ./pixman-arm-neon-asm.h:947: Warning: ignoring redefinition of register alias 'dst_w' ./pixman-arm-neon-asm.h:947: Warning: ignoring redefinition of register alias 'src' ./pixman-arm-neon-asm.h:947: Warning: ignoring redefinition of register alias 'mask' ./pixman-arm-neon-asm.h:947: Warning: ignoring redefinition of register alias 'dst_w' ./pixman-arm-neon-asm.h:947: Warning: ignoring redefinition of register alias 'src' ./pixman-arm-neon-asm.h:947: Warning: ignoring redefinition of register alias 'mask' ./pixman-arm-neon-asm.h:947: Warning: ignoring redefinition of register alias 'dst_w' ./pixman-arm-neon-asm.h:947: Warning: ignoring redefinition of register alias 'src' ./pixman-arm-neon-asm.h:947: Warning: ignoring redefinition of register alias 'mask' ./pixman-arm-neon-asm.h:947: Warning: ignoring redefinition of register alias 'dst_w' ./pixman-arm-neon-asm.h:947: Warning: ignoring redefinition of register alias 'src' ./pixman-arm-neon-asm.h:947: Warning: ignoring redefinition of register alias 'mask' ./pixman-arm-neon-asm.h:947: Warning: ignoring redefinition of register alias 'dst_w' ./pixman-arm-neon-asm.h:947: Warning: ignoring redefinition of register alias 'src' ./pixman-arm-neon-asm.h:947: Warning: ignoring redefinition of register alias 'mask' ./pixman-arm-neon-asm.h:947: Warning: ignoring redefinition of register alias 'dst_w' ./pixman-arm-neon-asm.h:947: Warning: ignoring redefinition of register alias 'src' ./pixman-arm-neon-asm.h:947: Warning: ignoring redefinition of register alias 'mask' pixman-arm-neon-asm.S:3623: Warning: ignoring redefinition of register alias 'tmp1' pixman-arm-neon-asm.S:3623: Warning: ignoring redefinition of register alias 'tmp2' pixman-arm-neon-asm.S:3627: Warning: ignoring redefinition of register alias 'tmp1' pixman-arm-neon-asm.S:3627: Warning: ignoring redefinition of register alias 'tmp2' pixman-arm-neon-asm.S:3631: Warning: ignoring redefinition of register alias 'tmp1' pixman-arm-neon-asm.S:3631: Warning: ignoring redefinition of register alias 'tmp2' pixman-arm-neon-asm.S:3635: Warning: ignoring redefinition of register alias 'tmp1' pixman-arm-neon-asm.S:3635: Warning: ignoring redefinition of register alias 'tmp2' cc: error: assembler command failed with exit code 1 (use -v to see invocation) Any suggestions? -- George --------------000600030505060805040308 Content-Type: text/plain; charset=us-ascii; name="dev_net.c.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="dev_net.c.patch" --- /usr/src/sys/boot/common/dev_net.c.orig 2013-08-30 13:25:49.000000000 -0400 +++ /usr/src/sys/boot/common/dev_net.c 2013-08-31 08:27:47.000000000 -0400 @@ -325,7 +325,7 @@ #endif d = socktodesc(sock); - sprintf(temp, "%6D", d->myea, ":"); + sprintf(temp, "%02x:%02x:%02x:%02x:%02x:%02x", d->myea[0], d->myea[1], d->myea[2], d->myea[3], d->myea[4], d->myea[5]); setenv("boot.netif.ip", inet_ntoa(myip), 1); setenv("boot.netif.netmask", intoa(netmask), 1); setenv("boot.netif.gateway", inet_ntoa(gateip), 1); --------------000600030505060805040308-- From owner-freebsd-arm@FreeBSD.ORG Sun Sep 15 16:39:20 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 4B0D2C66 for ; Sun, 15 Sep 2013 16:39:20 +0000 (UTC) (envelope-from pmather@vt.edu) Received: from lennier.cc.vt.edu (lennier.cc.vt.edu [198.82.162.213]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 004992A3A for ; Sun, 15 Sep 2013 16:39:19 +0000 (UTC) Received: from mr3.cc.vt.edu (mr3.cc.vt.edu [198.82.141.68]) by lennier.cc.vt.edu (8.13.8/8.13.8) with ESMTP id r8FENBZS009750 for ; Sun, 15 Sep 2013 10:23:11 -0400 Received: from mail-qa0-f54.google.com (mail-qa0-f54.google.com [209.85.216.54]) by mr3.cc.vt.edu (8.14.4/8.14.4) with ESMTP id r8FENB8c001678 for ; Sun, 15 Sep 2013 10:23:11 -0400 Received: by mail-qa0-f54.google.com with SMTP id bv4so525791qab.6 for ; Sun, 15 Sep 2013 07:23:11 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=squNp8ScGDEEwHMRqU0PU41weqXR4dYnXWl5WpKjxFU=; b=DdlLcKc3qfLTw0XXragb/F6646S/057MNF4RihJpo4O4RAtGpII9q6RWAxGYnwmJMn NWkGkMuqRv5AHGBWwOfBhnUE/G5+EWEF6lPypHhwiBIzNSTO2XSdwjB7mYQH4Mn8GQcs mNtROgtZvy/SzcsCwT2VT9++k3JCNLdg05+xh0shMLxh7p0qZ3tqXWmcK4FKOR3ZggpP 6+3nuI7UGze0rYpL4je1krothkltAaQhChw1fcZYlU7t2QZn2K6R/4l7pEa1IH1gKfe0 1AJo3SwrlalZCR/oPXGCDJPIE9YLzuQ+QhlobaHILgey8neoWQZKenHCqLO7E9Paw22L Pb8Q== X-Gm-Message-State: ALoCoQlkG+QahuNTyGmTFCKnH8fgTFURQv84qpzCWzMUBTApylADfxVlUs1J1EsIym56dG1ZjlHyZSST/boJ4rowOZ3JK8RVNBbtvnhpkAkWAnvRbz7IbN9aN21lZhAgHjp7m+JbxeIz7kJlWK/rgoEw95QbNK8AhZTdcJ6IN1GHNXcGTjPf1Dc= X-Received: by 10.224.89.5 with SMTP id c5mr8403748qam.32.1379254990990; Sun, 15 Sep 2013 07:23:10 -0700 (PDT) X-Received: by 10.224.89.5 with SMTP id c5mr8403741qam.32.1379254990931; Sun, 15 Sep 2013 07:23:10 -0700 (PDT) Received: from macbook.chumby.lan (c-98-249-9-133.hsd1.va.comcast.net. [98.249.9.133]) by mx.google.com with ESMTPSA id a2sm39150748qek.7.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 15 Sep 2013 07:23:10 -0700 (PDT) Subject: Re: sshd isnt working? Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Paul Mather In-Reply-To: <20130915120005.GA16617@night.db.net> Date: Sun, 15 Sep 2013 10:23:08 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <92A05C0F-B921-4998-8AF5-E0B4994E37D5@g.mail.vt.edu> References: <20130915120005.GA16617@night.db.net> To: Diane Bruce X-Mailer: Apple Mail (2.1283) Cc: freebsd-arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Sep 2013 16:39:20 -0000 On Sep 15, 2013, at 8:00 AM, Diane Bruce wrote: > On Sun, Sep 15, 2013 at 01:39:42PM +0800, Su Kang Yin wrote: >> Hi, >>=20 >> sshd throwing signal 6 on server side >>=20 >> messages log: >> Sep 15 05:32:31 beaglebone kernel: pid 896 (sshd), uid 22: exited on = signal 6 >>=20 >> On FreeBSD version: >> FreeBSD beaglebone 10.0-ALPHA1 FreeBSD 10.0-ALPHA1 #0 r255586: Sun = Sep >> 15 12:53:16 HKT 2013 >> root@freebsd:/usr/home/cantona/crochet-freebsd/work/obj/arm.a >> rmv6/usr/src.head/sys/BEAGLEBONE arm >>=20 > ... >>=20 >> Anyone have an idea about this problem? >=20 > Yes. >=20 > = http://docs.freebsd.org/cgi/getmsg.cgi?fetch=3D199241+0+archive/2013/freeb= sd-arm/20130728.freebsd-arm >=20 > I see you rediscovered this as well. >=20 > I did poke at it a bit more and found >=20 > = http://docs.freebsd.org/cgi/getmsg.cgi?fetch=3D47500+0+archive/2013/freebs= d-arm/20130825.freebsd-arm >=20 > zbb and Matthias Meyser reported another weird jemalloc error which is > in PR 182060 >=20 > http://www.freebsd.org/cgi/query-pr.cgi?pr=3D182060&cat=3D >=20 > I believe this is the exact same problem manifesting itself elsewhere. >=20 > I suspect we have a locking problem in the mutex code used on armv6. >=20 >=20 >> Thanks, >> Yin >=20 > - Diane > --=20 > - db@FreeBSD.org db@db.net http://www.db.net/~db For me, I've only encountered this problem when connecting from certain = clients---Mac OS X 10.7 and 10.8 so far. I can SSH to my Raspberry Pi = and BeagleBone Black just fine from another RELENG_9 FreeBSD system, and = from a Debian Wheezy system. The failure mode for those that don't work = is the same as reported above---a signal 6 on the server side. Also, = this hasn't always been the case, but I can't recall a revision number = when the problem began. Cheers, Paul. From owner-freebsd-arm@FreeBSD.ORG Sun Sep 15 16:43:16 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 718AFDA7 for ; Sun, 15 Sep 2013 16:43:16 +0000 (UTC) (envelope-from tim@kientzle.com) Received: from mail-pd0-f179.google.com (mail-pd0-f179.google.com [209.85.192.179]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 491452A77 for ; Sun, 15 Sep 2013 16:43:15 +0000 (UTC) Received: by mail-pd0-f179.google.com with SMTP id v10so3167748pde.24 for ; Sun, 15 Sep 2013 09:43:15 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=224zqQ6Nmutd2PLaV351LVAdKwsSREevl6t3JgYQBVM=; b=OndwtO9LRcpc6u0MtO1QB2kk+TC03qgI0vjU25IjI4BZLKY3GFW5OdLpa+lXYFhc7Y bsKkCgAnKK1scvzQcN13Vt0Bjg1DJWKaejVL8Aaq7PqPCGlxaj+e/o227o6NENRQIqDJ /+vM9b6PAhKdseE+zPyQm0lih6jQvM6+MR2sEOhPbzvlXonxL0nYFxskRO0jjd5pI6so SLJTvLOQOdgiuaaoFOIrIZq2c4xWvUPDPteYH/mGjBHb6VBG8jEDYlfAYdjRXtpudpI9 9O5/2dXV+gEFbr7Lack3ujqUMJL6kQpqLvRFFTTSRPv6ISc2mYl1wbiPKxTtrBjkMZ71 sy6w== X-Gm-Message-State: ALoCoQnXnZF48OwHeR+J+ONChZ7ozCr2Ge2HO5dv/jePquWj3cy+knq9wpunHB4aTR4cx5yjsMcN X-Received: by 10.68.168.99 with SMTP id zv3mr1991451pbb.144.1379263049391; Sun, 15 Sep 2013 09:37:29 -0700 (PDT) Received: from [192.168.1.74] (99-74-169-43.lightspeed.sntcca.sbcglobal.net. [99.74.169.43]) by mx.google.com with ESMTPSA id os4sm25329563pbb.25.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 15 Sep 2013 09:37:28 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Subject: Re: crochet failing when installing ubldr From: Tim Kientzle In-Reply-To: <1379250419.1197.43.camel@revolution.hippie.lan> Date: Sun, 15 Sep 2013 09:37:26 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <9D6FACB2-015D-4CE8-98F0-01AA501F1367@kientzle.com> References: <52354E8F.1010808@makani-kai.com> <1379250419.1197.43.camel@revolution.hippie.lan> To: werner@makani-kai.com X-Mailer: Apple Mail (2.1508) Cc: freebsd-arm@freebsd.org, Ian Lepore X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Sep 2013 16:43:16 -0000 On Sep 15, 2013, at 6:06 AM, Ian Lepore wrote: > On Sat, 2013-09-14 at 20:07 -1000, Werner Thie wrote: >> Hi Tim >>=20 >> sorry for bugging you, but crochet is failing when installing ubldr >>=20 >> sh /usr/local/src/tools/install.sh -o root -g wheel -m 444=20 >> /usr/local/src/sys/boot/arm/uboot/../../forth/loader.conf=20 >> = /home/wthie/proj/crochet-freebsd/work/ubldr-armv6-BEAGLEBONE-NOWITNESS//bo= ot/defaults/loader.conf What is the error message? Does the target directory exist? >> which seems very strange (path has a double // in front of boot). As Ian said, this is purely cosmetic. (Nice to fix but shouldn't break = anything.) Tim From owner-freebsd-arm@FreeBSD.ORG Sun Sep 15 18:19:55 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 13EC3861 for ; Sun, 15 Sep 2013 18:19:55 +0000 (UTC) (envelope-from beattidp@ieee.org) Received: from mail-pb0-f48.google.com (mail-pb0-f48.google.com [209.85.160.48]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id DFB1D2E50 for ; Sun, 15 Sep 2013 18:19:54 +0000 (UTC) Received: by mail-pb0-f48.google.com with SMTP id ma3so3177545pbc.7 for ; Sun, 15 Sep 2013 11:19:48 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:content-type:date:subject:to:message-id :mime-version; bh=h/+ao0ktP8x9nh0OPvN4guZizFHFk5jiUWu0QYXeaI8=; b=JUNdYFBsTiQXKLuVkXl4/pygfcz/cTW3iYIDTCWOqJF6bSppLun3H3L4TePe5S9qm2 /6vCwvWCVJ1DJvZ14jQha5+SXVrwUlBESDHONQvkrqiG3plVl9ftWF8iiuq7Q6Eje+Jd K4EisTr2hwH95jnkp9wqkt4wcDyE28Bsoj/UHxOLfTE9eI/H8AhRp1hzw7LRpie1FZCN S+Fwuv7ZO+7g4NLHoozCYT0nCLqNI5J3L6MTA0hS4uY5ZyX0taPf5Jvqv50NyJDYBldU 2rb6zS+A6meh/s++Fmn6+K3Kv6fzV3WRuhqr7aFQ69cMAjp0fcCWMglezp5fMGi81o6p N4hA== X-Gm-Message-State: ALoCoQmF+gXXoH6hv/6YtOFQOGDddhp7lfejCVkQDD76Spg1VR86XfvIRluHlXOZoU5dF35m9dIw X-Received: by 10.66.145.132 with SMTP id su4mr27025180pab.11.1379269188084; Sun, 15 Sep 2013 11:19:48 -0700 (PDT) Received: from [192.168.0.114] (75-162-208-106.slkc.qwest.net. [75.162.208.106]) by mx.google.com with ESMTPSA id gg10sm25739765pbc.46.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 15 Sep 2013 11:19:47 -0700 (PDT) From: Douglas Beattie Date: Sun, 15 Sep 2013 12:19:45 -0600 Subject: Building core-specific ARM ports with QEMU To: freebsd-arm Message-Id: Mime-Version: 1.0 (Apple Message framework v1283) X-Mailer: Apple Mail (2.1283) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Sep 2013 18:19:55 -0000 I'm still researching the issue of an ARM ports repository, whether it's = a private one for internal use, or eventually hosted on the Internet. One question I have is: if Tinderbox is for building the kernel, what = type of automated build tools (with reporting/tracking), if any, are = available for the FreeBSD ports? Anyway, here's my thought: I have access to a dual-Xeon Proliant server, which I can provision any reasonable number of FreeBSD VMs (virtual machines) within. Many of you probably know of QEMU, the open-source processor emulator. Using the executable 'qemu-system-arm' to simulate certain ARM cores, dedicated ARM systems could run and build ports (or attempt to, and = report their result, and any failures). Taking a look at the documentation, this strategy could provide a = variety of different ARM cores for building FreeBSD ports. http://qemu.weilnetz.de/qemu-doc.html#ARM-System-emulator - ARM Integrator/CP board emulation supports cores including ARM926E, ARM1026E, ARM946E, ARM1136 or Cortex-A8 CPU - Other board emulations support cores including ARM925T, ARMv5TE, Cortex-M3, ARM11MPCore, and Cortex-A9 MPCore As I mentioned previously, I used to boot debian-arm kernel this way, = with disk, network, and optional NFS access. (More links, = http://wiki.qemu.org/Manual ) My reasoning here is that the effort to make solid ports for certain = cores and board emulations will pay for itself in the ability to build and validate = FreeBSD ports for ARM variants, built in parallel, by multiple virtual machines, in the = cloud. So, the big question I have at the moment is: which of these board = emulations (if any), and which ARM cores are currently supported to boot from? -- Douglas Beattie http://www.hytherion.com/beattidp/ From owner-freebsd-arm@FreeBSD.ORG Sun Sep 15 19:57:24 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 982B6C1C for ; Sun, 15 Sep 2013 19:57:24 +0000 (UTC) (envelope-from werner@makani-kai.com) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 6129C22B1 for ; Sun, 15 Sep 2013 19:57:23 +0000 (UTC) Received: from agora.local (udp004035uds.hawaiiantel.net [72.234.77.213]) by mrelay.perfora.net (node=mrus3) with ESMTP (Nemesis) id 0MJjCu-1VKCVX0oHU-001vZ2; Sun, 15 Sep 2013 15:56:56 -0400 Message-ID: <52361103.80001@makani-kai.com> Date: Sun, 15 Sep 2013 09:56:51 -1000 From: Werner Thie Organization: Makani Kai LLC User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: freebsd-arm@freebsd.org Subject: Re: crochet failing when installing ubldr References: <52354E8F.1010808@makani-kai.com> <1379250419.1197.43.camel@revolution.hippie.lan> <9D6FACB2-015D-4CE8-98F0-01AA501F1367@kientzle.com> In-Reply-To: <9D6FACB2-015D-4CE8-98F0-01AA501F1367@kientzle.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V02:K0:GMIGK/244D8xTVqebP7Bn43lQrjYhKmRlV1wGmNL7qh 5XcYcBGNWV9UNt4RIKDpKdmjTZ4P8rWxEAEDuhXk/44ASjU1Pp 84lLPb3CwThxv4C7EoN4CXYcqTNmNHYS2nhKVfi+MiEwNs6O5K m8G57KLDStIgMQmlxRrPqQxSpnazmbP7oYB2NVWEOQz9UmPwHG v++I+66aLiYUpPWztAnCGWV4VT5ze+UdH4VNS9JKr/z7swayfc +3B/2eJIvb2CRcG7Uu43KOgz+LLM1oDCSGXnslVMf84/wjrxng 48h+lDdFEyn/OGlz3SY+8a5L8x5Xy3CMRbh7ZXMb+eoTa2sq1U 9ebVCQixxEyZDcXY1JzU= X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: werner@makani-kai.com List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Sep 2013 19:57:24 -0000 On 9/15/13 6:37 AM, Tim Kientzle wrote: > > On Sep 15, 2013, at 6:06 AM, Ian Lepore wrote: > >> On Sat, 2013-09-14 at 20:07 -1000, Werner Thie wrote: >>> Hi Tim >>> >>> sorry for bugging you, but crochet is failing when installing ubldr >>> >>> sh /usr/local/src/tools/install.sh -o root -g wheel -m 444 >>> /usr/local/src/sys/boot/arm/uboot/../../forth/loader.conf >>> /home/wthie/proj/crochet-freebsd/work/ubldr-armv6-BEAGLEBONE-NOWITNESS//boot/defaults/loader.conf > > What is the error message? > > Does the target directory exist? > > >>> which seems very strange (path has a double // in front of boot). > > As Ian said, this is purely cosmetic. (Nice to fix but shouldn't break anything.) > > Tim Aloha now this is even stranger, restarting crochet.sh again installed ubldr now without a hitch. I'll report later if this is a one off situation when creating everything anew Mahalo, Werner From owner-freebsd-arm@FreeBSD.ORG Sun Sep 15 21:15:29 2013 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 16A627E3; Sun, 15 Sep 2013 21:15:29 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from smtpauth4.wiscmail.wisc.edu (wmauth4.doit.wisc.edu [144.92.197.145]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id E05DC262E; Sun, 15 Sep 2013 21:15:28 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII; format=flowed Received: from avs-daemon.smtpauth4.wiscmail.wisc.edu by smtpauth4.wiscmail.wisc.edu (Oracle Communications Messaging Server 7u4-27.01(7.0.4.27.0) 64bit (built Aug 30 2012)) id <0MT600E00QYXZZ00@smtpauth4.wiscmail.wisc.edu>; Sun, 15 Sep 2013 16:15:27 -0500 (CDT) X-Spam-PmxInfo: Server=avs-4, Version=6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2013.9.15.210619, SenderIP=0.0.0.0 X-Spam-Report: AuthenticatedSender=yes, SenderIP=0.0.0.0 Received: from comporellon.tachypleus.net (adsl-76-208-67-251.dsl.mdsnwi.sbcglobal.net [76.208.67.251]) by smtpauth4.wiscmail.wisc.edu (Oracle Communications Messaging Server 7u4-27.01(7.0.4.27.0) 64bit (built Aug 30 2012)) with ESMTPSA id <0MT60028FR1Q2T10@smtpauth4.wiscmail.wisc.edu>; Sun, 15 Sep 2013 16:15:27 -0500 (CDT) Message-id: <5236236E.5060502@freebsd.org> Date: Sun, 15 Sep 2013 16:15:26 -0500 From: Nathan Whitehorn User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130907 Thunderbird/17.0.8 To: Ian Lepore Subject: Re: AVILA kernel References: <522F346D.9000609@freebsd.org> <1378826132.1111.592.camel@revolution.hippie.lan> In-reply-to: <1378826132.1111.592.camel@revolution.hippie.lan> Cc: "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Sep 2013 21:15:29 -0000 On 09/10/13 10:15, Ian Lepore wrote: > On Tue, 2013-09-10 at 10:02 -0500, Nathan Whitehorn wrote: >> Has anyone succeeded in booting the AVILA kernel recently? I get up to >> the copyright message and the compiler ID string and then the kernel >> hangs up and never does anything ever again. > I think a good next step for that would be to add option VERBOSE_SYSINIT > because once you've gotten the copyright it's past the tricky stuff like > early pmap setup, and probably into the sysinits. > > -- Ian > > This is what I get. Symbols aren't loaded, so I'm not really sure how useful it is in the end. The configuration in question is a modified one. The stock AVILA configuration gives the highly suspicious: panic: mtx_lock() of spin mutex pmap @ /usr/src/sys/arm/arm/pmap.c:3676 -Nathan KDB: debugger backends: ddb KDB: current backend: ddb Copyright (c) 1992-2013 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 10.0-ALPHA1 #4 r255602M: Sun Sep 15 16:09:00 CDT 2013 root@comporellon.tachypleus.net:/usr/obj/arm.armeb/usr/src/sys/LIMULUS arm gcc version 4.2.1 20070831 patched [FreeBSD] subsystem 900000 0xc0304b74(0)... done. subsystem 1000000 0xc056974c(0)... done. 0xc0578294(0)... done. subsystem 1800000 0xc03011f0(0)... done. 0xc0301650(0xc0681040)... From owner-freebsd-arm@FreeBSD.ORG Sun Sep 15 21:19:56 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id B7FDB937 for ; Sun, 15 Sep 2013 21:19:56 +0000 (UTC) (envelope-from paul@gromit.dlib.vt.edu) Received: from lennier.cc.vt.edu (lennier.cc.vt.edu [198.82.162.213]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 7571A264B for ; Sun, 15 Sep 2013 21:19:55 +0000 (UTC) Received: from mr1.cc.vt.edu (mr1.cc.vt.edu [198.82.141.12]) by lennier.cc.vt.edu (8.13.8/8.13.8) with ESMTP id r8FLJNWK017561 for ; Sun, 15 Sep 2013 17:19:24 -0400 Received: from auth1.smtp.vt.edu (auth1.smtp.vt.edu [198.82.161.152]) by mr1.cc.vt.edu (8.14.4/8.14.4) with ESMTP id r8FLJNUo004557 for ; Sun, 15 Sep 2013 17:19:23 -0400 Received: from gromit.chumby.lan (c-98-249-9-133.hsd1.va.comcast.net [98.249.9.133]) (authenticated bits=0) by auth1.smtp.vt.edu (8.14.4/8.14.4) with ESMTP id r8FLJMLu023746 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Sun, 15 Sep 2013 17:19:22 -0400 From: Paul Mather Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: A successful native build using clang at last---just! Message-Id: <581873CA-BFB9-4287-9DFE-46A262B4459A@gromit.dlib.vt.edu> Date: Sun, 15 Sep 2013 17:19:21 -0400 To: freebsd-arm Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) X-Mailer: Apple Mail (2.1508) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Sep 2013 21:19:56 -0000 After quite a bit of trying, I finally was able to complete a native = build and upgrade using clang on FreeBSD/arm. I used r255420 as the = build platform and was able to upgrade to r255586 on my Raspberry Pi. Here are some observations: 1) For some reason this same upgrade failed on my BeagleBone Black (also = running r255420). It fails early on with this error and doesn't get = past it: [[...]] c++ -O -pipe = -I/usr/src/lib/clang/libllvmtablegen/../../../contrib/llvm/include = -I/usr/src/lib/clang/libllvmtablegen/../../../contrib/llvm/tools/clang/inc= lude = -I/usr/src/lib/clang/libllvmtablegen/../../../contrib/llvm/lib/TableGen = -I. = -I/usr/src/lib/clang/libllvmtablegen/../../../contrib/llvm/../../lib/clang= /include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS = -D__STDC_CONSTANT_MACROS -fno-strict-aliasing = -DLLVM_DEFAULT_TARGET_TRIPLE=3D\"armv6-gnueabi-freebsd10.0\" = -DLLVM_HOST_TRIPLE=3D\"armv6-unknown-freebsd10.0\" = -DDEFAULT_SYSROOT=3D\"\" -I/usr/obj/usr/src/tmp/legacy/usr/include = -Wno-c++11-extensions -fno-exceptions -fno-rtti -c = /usr/src/lib/clang/libllvmtablegen/../../../contrib/llvm/lib/TableGen/TGPa= rser.cpp -o TGParser.o Assertion failed: (!FoundVal && "Key already in new map?"), function = moveFromOldBuckets, file = /usr/src/lib/clang/libclangast/../../../contrib/llvm/include/llvm/ADT/Dens= eMap.h, line 289. Stack dump: 0. Program arguments: /usr/bin/c++ -cc1 -triple = armv6--freebsd10.0-gnueabi -S -disable-free -main-file-name TGParser.cpp = -mrelocation-model static -mdisable-fp-elim -relaxed-aliasing = -mconstructor-aliases -target-abi aapcs-linux -target-cpu arm1136jf-s = -msoft-float -mfloat-abi soft -target-feature +soft-float = -target-feature +soft-float-abi -target-feature -neon -coverage-file = /tmp/TGParser-KtbaOq.s -resource-dir /usr/bin/../lib/clang/3.3 -D = LLVM_ON_UNIX -D LLVM_ON_FREEBSD -D __STDC_LIMIT_MACROS -D = __STDC_CONSTANT_MACROS -D = LLVM_DEFAULT_TARGET_TRIPLE=3D"armv6-gnueabi-freebsd10.0" -D = LLVM_HOST_TRIPLE=3D"armv6-unknown-freebsd10.0" -D DEFAULT_SYSROOT=3D"" = -I /usr/src/lib/clang/libllvmtablegen/../../../contrib/llvm/include -I = /usr/src/lib/clang/libllvmtablegen/../../../contrib/llvm/tools/clang/inclu= de -I = /usr/src/lib/clang/libllvmtablegen/../../../contrib/llvm/lib/TableGen -I = . -I = /usr/src/lib/clang/libllvmtablegen/../../../contrib/llvm/../../lib/clang/i= nclude -I /usr/obj/usr/src/tmp/legacy/usr/include -internal-isystem = /usr/include/c++/v1 -O2 -Wno-c++11-extensions -fdeprecated-macro = -fno-dwarf-directory-asm -fdebug-compilation-dir = /usr/obj/usr/src/tmp/usr/src/lib/clang/libllvmtablegen -ferror-limit 19 = -fmessage-length 0 -mstackrealign -fno-rtti -fno-signed-char = -fobjc-runtime=3Dgnustep -fobjc-default-synthesize-properties = -fdiagnostics-show-option -backend-option -vectorize-loops -o = /tmp/TGParser-KtbaOq.s -x c++ = /usr/src/lib/clang/libllvmtablegen/../../../contrib/llvm/lib/TableGen/TGPa= rser.cpp=20 1. /usr/include/c++/v1/locale:3072:48: current parser token 'init' 2. /usr/include/c++/v1/locale:205:1 = : parsing namespace = 'std' 3. /usr/include/c++/v1/locale:205:1 = : parsing namespace = '__1' c++: error: unable to execute command: Abort trap (core dumped) c++: error: clang frontend command failed due to signal (use -v to see = invocation) FreeBSD clang version 3.3 (tags/RELEASE_33/final 183502) 20130610 Target: armv6--freebsd10.0-gnueabi Thread model: posix c++: note: diagnostic msg: PLEASE submit a bug report to = http://llvm.org/bugs/ and include the crash backtrace, preprocessed = source, and associated run script. c++: note: diagnostic msg: Error generating preprocessed source(s). *** Error code 254 Stop. make[3]: stopped in /usr/src/lib/clang/libllvmtablegen *** Error code 1 Stop. make[2]: stopped in /usr/src *** Error code 1 Stop. make[1]: stopped in /usr/src *** Error code 1 Stop. make: stopped in /usr/src 2) The successful upgrade on Raspberry Pi had to be restarted a couple = of times (using -DNO_CLEAN) due to hangs. I have noticed problems with = the system when swap is used. Paging out to swap seems okay, but = processes appear to die when they are paged back in from swap. = Sometimes, this hangs the system. 3) FWIW, I am running with super pages enabled: vm.pmap.sp_enabled=3D1. Cheers, Paul.= From owner-freebsd-arm@FreeBSD.ORG Sun Sep 15 21:41:10 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id E89EE14B for ; Sun, 15 Sep 2013 21:41:10 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-pb0-f51.google.com (mail-pb0-f51.google.com [209.85.160.51]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id BF96B2771 for ; Sun, 15 Sep 2013 21:41:10 +0000 (UTC) Received: by mail-pb0-f51.google.com with SMTP id jt11so3280044pbb.24 for ; Sun, 15 Sep 2013 14:41:04 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=T83ochx9cH2P2phbzdM9pCJsAG0gBGc8c92YPXKcv0k=; b=TcSVzijP5f9H0RPxwuHEKxzBoiCMvUUU3DRw5DIO1DMJ1imKCkIHzI7DDBCTd+eF+Z cLBdBAY8QbYc7IydRpVAw7es6VvuqavWHXdzqz6wzO8jIF5mVQwzV6wMz5G6Aywa0jPi SS1mvEJBVROpo7mLxL1drUtLtJSV8G7DwZxpS/ZavPQtykQsnm9ZnHSHqWcqj4GlLN5h VZg97LXafXIoqIxsPeRBpvvp9yTgy/6ztB+p35SerZnOOnRaGUTDQ4vxp9Y8NnGuvqXK I8ZrYwvZK/noefRT95GlQDU4Q3QMRbha7pvluYkZwTgn2zET2lRllBTW10bogrqQT7sn yLcg== X-Gm-Message-State: ALoCoQm77DicnJY3oi9HuxRLSdPs6MUdX1uXrEOwFov+APdU3XNQf8YGX0dTqoNgjTIweZsKz42J X-Received: by 10.68.196.234 with SMTP id ip10mr25725419pbc.18.1379280899714; Sun, 15 Sep 2013 14:34:59 -0700 (PDT) Received: from 53.imp.bsdimp.com (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPSA id ht5sm26413253pbb.29.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 15 Sep 2013 14:34:59 -0700 (PDT) Sender: Warner Losh Subject: Re: A successful native build using clang at last---just! Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <581873CA-BFB9-4287-9DFE-46A262B4459A@gromit.dlib.vt.edu> Date: Sun, 15 Sep 2013 15:34:57 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <581873CA-BFB9-4287-9DFE-46A262B4459A@gromit.dlib.vt.edu> To: Paul Mather X-Mailer: Apple Mail (2.1085) Cc: freebsd-arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Sep 2013 21:41:11 -0000 Do you have swap space configured? clang building clang takes a lot of = memory... Warner On Sep 15, 2013, at 3:19 PM, Paul Mather wrote: > After quite a bit of trying, I finally was able to complete a native = build and upgrade using clang on FreeBSD/arm. I used r255420 as the = build platform and was able to upgrade to r255586 on my Raspberry Pi. >=20 > Here are some observations: >=20 > 1) For some reason this same upgrade failed on my BeagleBone Black = (also running r255420). It fails early on with this error and doesn't = get past it: >=20 > [[...]] > c++ -O -pipe = -I/usr/src/lib/clang/libllvmtablegen/../../../contrib/llvm/include = -I/usr/src/lib/clang/libllvmtablegen/../../../contrib/llvm/tools/clang/inc= lude = -I/usr/src/lib/clang/libllvmtablegen/../../../contrib/llvm/lib/TableGen = -I. = -I/usr/src/lib/clang/libllvmtablegen/../../../contrib/llvm/../../lib/clang= /include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS = -D__STDC_CONSTANT_MACROS -fno-strict-aliasing = -DLLVM_DEFAULT_TARGET_TRIPLE=3D\"armv6-gnueabi-freebsd10.0\" = -DLLVM_HOST_TRIPLE=3D\"armv6-unknown-freebsd10.0\" = -DDEFAULT_SYSROOT=3D\"\" -I/usr/obj/usr/src/tmp/legacy/usr/include = -Wno-c++11-extensions -fno-exceptions -fno-rtti -c = /usr/src/lib/clang/libllvmtablegen/../../../contrib/llvm/lib/TableGen/TGPa= rser.cpp -o TGParser.o > Assertion failed: (!FoundVal && "Key already in new map?"), function = moveFromOldBuckets, file = /usr/src/lib/clang/libclangast/../../../contrib/llvm/include/llvm/ADT/Dens= eMap.h, line 289. > Stack dump: > 0. Program arguments: /usr/bin/c++ -cc1 -triple = armv6--freebsd10.0-gnueabi -S -disable-free -main-file-name TGParser.cpp = -mrelocation-model static -mdisable-fp-elim -relaxed-aliasing = -mconstructor-aliases -target-abi aapcs-linux -target-cpu arm1136jf-s = -msoft-float -mfloat-abi soft -target-feature +soft-float = -target-feature +soft-float-abi -target-feature -neon -coverage-file = /tmp/TGParser-KtbaOq.s -resource-dir /usr/bin/../lib/clang/3.3 -D = LLVM_ON_UNIX -D LLVM_ON_FREEBSD -D __STDC_LIMIT_MACROS -D = __STDC_CONSTANT_MACROS -D = LLVM_DEFAULT_TARGET_TRIPLE=3D"armv6-gnueabi-freebsd10.0" -D = LLVM_HOST_TRIPLE=3D"armv6-unknown-freebsd10.0" -D DEFAULT_SYSROOT=3D"" = -I /usr/src/lib/clang/libllvmtablegen/../../../contrib/llvm/include -I = /usr/src/lib/clang/libllvmtablegen/../../../contrib/llvm/tools/clang/inclu= de -I = /usr/src/lib/clang/libllvmtablegen/../../../contrib/llvm/lib/TableGen -I = . -I = /usr/src/lib/clang/libllvmtablegen/../../../contrib/llvm/../../lib/clang/i= nclude -I /usr/obj/usr/src/tmp/l > egacy/usr/include -internal-isystem /usr/include/c++/v1 -O2 = -Wno-c++11-extensions -fdeprecated-macro -fno-dwarf-directory-asm = -fdebug-compilation-dir = /usr/obj/usr/src/tmp/usr/src/lib/clang/libllvmtablegen -ferror-limit 19 = -fmessage-length 0 -mstackrealign -fno-rtti -fno-signed-char = -fobjc-runtime=3Dgnustep -fobjc-default-synthesize-properties = -fdiagnostics-show-option -backend-option -vectorize-loops -o = /tmp/TGParser-KtbaOq.s -x c++ = /usr/src/lib/clang/libllvmtablegen/../../../contrib/llvm/lib/TableGen/TGPa= rser.cpp=20 > 1. /usr/include/c++/v1/locale:3072:48: current parser token 'init' > 2. /usr/include/c++/v1/locale:205:1 = : parsing namespace = 'std' > 3. /usr/include/c++/v1/locale:205:1 = : parsing namespace = '__1' > c++: error: unable to execute command: Abort trap (core dumped) > c++: error: clang frontend command failed due to signal (use -v to see = invocation) > FreeBSD clang version 3.3 (tags/RELEASE_33/final 183502) 20130610 > Target: armv6--freebsd10.0-gnueabi > Thread model: posix > c++: note: diagnostic msg: PLEASE submit a bug report to = http://llvm.org/bugs/ and include the crash backtrace, preprocessed = source, and associated run script. > c++: note: diagnostic msg: Error generating preprocessed source(s). > *** Error code 254 >=20 > Stop. > make[3]: stopped in /usr/src/lib/clang/libllvmtablegen > *** Error code 1 >=20 > Stop. > make[2]: stopped in /usr/src > *** Error code 1 >=20 > Stop. > make[1]: stopped in /usr/src > *** Error code 1 >=20 > Stop. > make: stopped in /usr/src >=20 > 2) The successful upgrade on Raspberry Pi had to be restarted a couple = of times (using -DNO_CLEAN) due to hangs. I have noticed problems with = the system when swap is used. Paging out to swap seems okay, but = processes appear to die when they are paged back in from swap. = Sometimes, this hangs the system. >=20 > 3) FWIW, I am running with super pages enabled: vm.pmap.sp_enabled=3D1. >=20 > Cheers, >=20 > Paul. > _______________________________________________ > 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 Sun Sep 15 21:53:40 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 9A6F2317 for ; Sun, 15 Sep 2013 21:53:40 +0000 (UTC) (envelope-from paul@gromit.dlib.vt.edu) Received: from lennier.cc.vt.edu (lennier.cc.vt.edu [198.82.162.213]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 5453927F0 for ; Sun, 15 Sep 2013 21:53:39 +0000 (UTC) Received: from mr2.cc.vt.edu (mr2.cc.vt.edu [198.82.163.74]) by lennier.cc.vt.edu (8.13.8/8.13.8) with ESMTP id r8FLqcim031874; Sun, 15 Sep 2013 17:52:38 -0400 Received: from auth1.smtp.vt.edu (auth1.smtp.vt.edu [198.82.161.152]) by mr2.cc.vt.edu (8.14.4/8.14.4) with ESMTP id r8FLqcTW028597; Sun, 15 Sep 2013 17:52:38 -0400 Received: from gromit.chumby.lan (c-98-249-9-133.hsd1.va.comcast.net [98.249.9.133]) (authenticated bits=0) by auth1.smtp.vt.edu (8.14.4/8.14.4) with ESMTP id r8FLqbKV028185 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 15 Sep 2013 17:52:38 -0400 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Subject: Re: A successful native build using clang at last---just! From: Paul Mather In-Reply-To: Date: Sun, 15 Sep 2013 17:52:37 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <48D945AB-1303-4ECB-9250-1DEA548FAECA@gromit.dlib.vt.edu> References: <581873CA-BFB9-4287-9DFE-46A262B4459A@gromit.dlib.vt.edu> To: Warner Losh X-Mailer: Apple Mail (2.1508) Cc: freebsd-arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Sep 2013 21:53:40 -0000 On Sep 15, 2013, at 5:34 PM, Warner Losh wrote: > Do you have swap space configured? clang building clang takes a lot of = memory... Yes, I have swap space configured (see item 2 below). It's on an = external USB drive (as are /usr/src and /usr/obj), and the swap = partition is 2 GB in size. Note, this is a native build. I don't have problems cross-building = FreeBSD/arm using Crochet on FreeBSD/amd64. Cheers, Paul. >=20 > Warner >=20 >=20 > On Sep 15, 2013, at 3:19 PM, Paul Mather wrote: >=20 >> After quite a bit of trying, I finally was able to complete a native = build and upgrade using clang on FreeBSD/arm. I used r255420 as the = build platform and was able to upgrade to r255586 on my Raspberry Pi. >>=20 >> Here are some observations: >>=20 >> 1) For some reason this same upgrade failed on my BeagleBone Black = (also running r255420). It fails early on with this error and doesn't = get past it: >>=20 >> [[...]] >> c++ -O -pipe = -I/usr/src/lib/clang/libllvmtablegen/../../../contrib/llvm/include = -I/usr/src/lib/clang/libllvmtablegen/../../../contrib/llvm/tools/clang/inc= lude = -I/usr/src/lib/clang/libllvmtablegen/../../../contrib/llvm/lib/TableGen = -I. = -I/usr/src/lib/clang/libllvmtablegen/../../../contrib/llvm/../../lib/clang= /include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS = -D__STDC_CONSTANT_MACROS -fno-strict-aliasing = -DLLVM_DEFAULT_TARGET_TRIPLE=3D\"armv6-gnueabi-freebsd10.0\" = -DLLVM_HOST_TRIPLE=3D\"armv6-unknown-freebsd10.0\" = -DDEFAULT_SYSROOT=3D\"\" -I/usr/obj/usr/src/tmp/legacy/usr/include = -Wno-c++11-extensions -fno-exceptions -fno-rtti -c = /usr/src/lib/clang/libllvmtablegen/../../../contrib/llvm/lib/TableGen/TGPa= rser.cpp -o TGParser.o >> Assertion failed: (!FoundVal && "Key already in new map?"), function = moveFromOldBuckets, file = /usr/src/lib/clang/libclangast/../../../contrib/llvm/include/llvm/ADT/Dens= eMap.h, line 289. >> Stack dump: >> 0. Program arguments: /usr/bin/c++ -cc1 -triple = armv6--freebsd10.0-gnueabi -S -disable-free -main-file-name TGParser.cpp = -mrelocation-model static -mdisable-fp-elim -relaxed-aliasing = -mconstructor-aliases -target-abi aapcs-linux -target-cpu arm1136jf-s = -msoft-float -mfloat-abi soft -target-feature +soft-float = -target-feature +soft-float-abi -target-feature -neon -coverage-file = /tmp/TGParser-KtbaOq.s -resource-dir /usr/bin/../lib/clang/3.3 -D = LLVM_ON_UNIX -D LLVM_ON_FREEBSD -D __STDC_LIMIT_MACROS -D = __STDC_CONSTANT_MACROS -D = LLVM_DEFAULT_TARGET_TRIPLE=3D"armv6-gnueabi-freebsd10.0" -D = LLVM_HOST_TRIPLE=3D"armv6-unknown-freebsd10.0" -D DEFAULT_SYSROOT=3D"" = -I /usr/src/lib/clang/libllvmtablegen/../../../contrib/llvm/include -I = /usr/src/lib/clang/libllvmtablegen/../../../contrib/llvm/tools/clang/inclu= de -I = /usr/src/lib/clang/libllvmtablegen/../../../contrib/llvm/lib/TableGen -I = . -I = /usr/src/lib/clang/libllvmtablegen/../../../contrib/llvm/../../lib/clang/i= nclude -I /usr/obj/usr/src/tmp/l >> egacy/usr/include -internal-isystem /usr/include/c++/v1 -O2 = -Wno-c++11-extensions -fdeprecated-macro -fno-dwarf-directory-asm = -fdebug-compilation-dir = /usr/obj/usr/src/tmp/usr/src/lib/clang/libllvmtablegen -ferror-limit 19 = -fmessage-length 0 -mstackrealign -fno-rtti -fno-signed-char = -fobjc-runtime=3Dgnustep -fobjc-default-synthesize-properties = -fdiagnostics-show-option -backend-option -vectorize-loops -o = /tmp/TGParser-KtbaOq.s -x c++ = /usr/src/lib/clang/libllvmtablegen/../../../contrib/llvm/lib/TableGen/TGPa= rser.cpp=20 >> 1. /usr/include/c++/v1/locale:3072:48: current parser token 'init' >> 2. /usr/include/c++/v1/locale:205:1 = : parsing namespace = 'std' >> 3. /usr/include/c++/v1/locale:205:1 = : parsing namespace = '__1' >> c++: error: unable to execute command: Abort trap (core dumped) >> c++: error: clang frontend command failed due to signal (use -v to = see invocation) >> FreeBSD clang version 3.3 (tags/RELEASE_33/final 183502) 20130610 >> Target: armv6--freebsd10.0-gnueabi >> Thread model: posix >> c++: note: diagnostic msg: PLEASE submit a bug report to = http://llvm.org/bugs/ and include the crash backtrace, preprocessed = source, and associated run script. >> c++: note: diagnostic msg: Error generating preprocessed source(s). >> *** Error code 254 >>=20 >> Stop. >> make[3]: stopped in /usr/src/lib/clang/libllvmtablegen >> *** Error code 1 >>=20 >> Stop. >> make[2]: stopped in /usr/src >> *** Error code 1 >>=20 >> Stop. >> make[1]: stopped in /usr/src >> *** Error code 1 >>=20 >> Stop. >> make: stopped in /usr/src >>=20 >> 2) The successful upgrade on Raspberry Pi had to be restarted a = couple of times (using -DNO_CLEAN) due to hangs. I have noticed = problems with the system when swap is used. Paging out to swap seems = okay, but processes appear to die when they are paged back in from swap. = Sometimes, this hangs the system. >>=20 >> 3) FWIW, I am running with super pages enabled: vm.pmap.sp_enabled=3D1.= >>=20 >> Cheers, >>=20 >> Paul. >> _______________________________________________ >> 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" >=20 From owner-freebsd-arm@FreeBSD.ORG Sun Sep 15 22:02:29 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 647FF3CC for ; Sun, 15 Sep 2013 22:02:29 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-pd0-f171.google.com (mail-pd0-f171.google.com [209.85.192.171]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 3978A284C for ; Sun, 15 Sep 2013 22:02:28 +0000 (UTC) Received: by mail-pd0-f171.google.com with SMTP id g10so3341276pdj.2 for ; Sun, 15 Sep 2013 15:02:22 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=impcZN/3icTEKjv/+gGnEdJ3bkXI2VNmIpK2ysj1pvM=; b=DZiHH0sBsdFpTZc8X8qcYrh3YMSxpnnsU043Sm6DuJNzauskP8LnL8+h8e/ZfeAcOn kdkq34KKgHA5I374tYTxqj7xtyrmpc0dhhUm1SXpDCMJN0T73niVvH8q1w83IWyw6xT3 116k+rXHexab3iKKFRibNOqB7NbnB5hSQSpy7Cna9zBLSUTbG/gtB6OBnVQI+3sZ1+io jIXQOFI8zsOonbU98YeAJFOB82zvKEzEmKMRviqh9EuGZdYLhqB3kBOy2W/2NSx68jDC 2lDzdW7uHSTbWYIlVe3xod2TlknLxE7FOMwgpsqre3V7WhW1XHncEXn7y541tvqMacTJ Pc0Q== X-Gm-Message-State: ALoCoQkjczmFhFTezmKnTRZVDMvCJW6ar5SGbeSz/TC6Jwk8fEwd0o/Bq5xHeIi9OdxXFbaPUpH3 X-Received: by 10.66.146.42 with SMTP id sz10mr27856038pab.100.1379282542180; Sun, 15 Sep 2013 15:02:22 -0700 (PDT) Received: from 53.imp.bsdimp.com (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPSA id ta10sm33737926pab.5.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 15 Sep 2013 15:02:21 -0700 (PDT) Sender: Warner Losh Subject: Re: A successful native build using clang at last---just! Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <48D945AB-1303-4ECB-9250-1DEA548FAECA@gromit.dlib.vt.edu> Date: Sun, 15 Sep 2013 16:02:19 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <144C741C-550E-4874-9F10-093959204270@bsdimp.com> References: <581873CA-BFB9-4287-9DFE-46A262B4459A@gromit.dlib.vt.edu> <48D945AB-1303-4ECB-9250-1DEA548FAECA@gromit.dlib.vt.edu> To: Paul Mather X-Mailer: Apple Mail (2.1085) Cc: freebsd-arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Sep 2013 22:02:29 -0000 On Sep 15, 2013, at 3:52 PM, Paul Mather wrote: > On Sep 15, 2013, at 5:34 PM, Warner Losh wrote: >=20 >> Do you have swap space configured? clang building clang takes a lot = of memory... >=20 > Yes, I have swap space configured (see item 2 below). It's on an = external USB drive (as are /usr/src and /usr/obj), and the swap = partition is 2 GB in size. 2GB might not be enough... I always configure 6GB of swap, but I use a = sparse zerod file to do it. Might be worth a shot... > Note, this is a native build. I don't have problems cross-building = FreeBSD/arm using Crochet on FreeBSD/amd64. Yea, amd64 machine likely has lots of memory... Warner > Cheers, >=20 > Paul. >=20 >>=20 >> Warner >>=20 >>=20 >> On Sep 15, 2013, at 3:19 PM, Paul Mather wrote: >>=20 >>> After quite a bit of trying, I finally was able to complete a native = build and upgrade using clang on FreeBSD/arm. I used r255420 as the = build platform and was able to upgrade to r255586 on my Raspberry Pi. >>>=20 >>> Here are some observations: >>>=20 >>> 1) For some reason this same upgrade failed on my BeagleBone Black = (also running r255420). It fails early on with this error and doesn't = get past it: >>>=20 >>> [[...]] >>> c++ -O -pipe = -I/usr/src/lib/clang/libllvmtablegen/../../../contrib/llvm/include = -I/usr/src/lib/clang/libllvmtablegen/../../../contrib/llvm/tools/clang/inc= lude = -I/usr/src/lib/clang/libllvmtablegen/../../../contrib/llvm/lib/TableGen = -I. = -I/usr/src/lib/clang/libllvmtablegen/../../../contrib/llvm/../../lib/clang= /include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS = -D__STDC_CONSTANT_MACROS -fno-strict-aliasing = -DLLVM_DEFAULT_TARGET_TRIPLE=3D\"armv6-gnueabi-freebsd10.0\" = -DLLVM_HOST_TRIPLE=3D\"armv6-unknown-freebsd10.0\" = -DDEFAULT_SYSROOT=3D\"\" -I/usr/obj/usr/src/tmp/legacy/usr/include = -Wno-c++11-extensions -fno-exceptions -fno-rtti -c = /usr/src/lib/clang/libllvmtablegen/../../../contrib/llvm/lib/TableGen/TGPa= rser.cpp -o TGParser.o >>> Assertion failed: (!FoundVal && "Key already in new map?"), function = moveFromOldBuckets, file = /usr/src/lib/clang/libclangast/../../../contrib/llvm/include/llvm/ADT/Dens= eMap.h, line 289. >>> Stack dump: >>> 0. Program arguments: /usr/bin/c++ -cc1 -triple = armv6--freebsd10.0-gnueabi -S -disable-free -main-file-name TGParser.cpp = -mrelocation-model static -mdisable-fp-elim -relaxed-aliasing = -mconstructor-aliases -target-abi aapcs-linux -target-cpu arm1136jf-s = -msoft-float -mfloat-abi soft -target-feature +soft-float = -target-feature +soft-float-abi -target-feature -neon -coverage-file = /tmp/TGParser-KtbaOq.s -resource-dir /usr/bin/../lib/clang/3.3 -D = LLVM_ON_UNIX -D LLVM_ON_FREEBSD -D __STDC_LIMIT_MACROS -D = __STDC_CONSTANT_MACROS -D = LLVM_DEFAULT_TARGET_TRIPLE=3D"armv6-gnueabi-freebsd10.0" -D = LLVM_HOST_TRIPLE=3D"armv6-unknown-freebsd10.0" -D DEFAULT_SYSROOT=3D"" = -I /usr/src/lib/clang/libllvmtablegen/../../../contrib/llvm/include -I = /usr/src/lib/clang/libllvmtablegen/../../../contrib/llvm/tools/clang/inclu= de -I = /usr/src/lib/clang/libllvmtablegen/../../../contrib/llvm/lib/TableGen -I = . -I = /usr/src/lib/clang/libllvmtablegen/../../../contrib/llvm/../../lib/clang/i= nclude -I /usr/obj/usr/src/tmp/l >>> egacy/usr/include -internal-isystem /usr/include/c++/v1 -O2 = -Wno-c++11-extensions -fdeprecated-macro -fno-dwarf-directory-asm = -fdebug-compilation-dir = /usr/obj/usr/src/tmp/usr/src/lib/clang/libllvmtablegen -ferror-limit 19 = -fmessage-length 0 -mstackrealign -fno-rtti -fno-signed-char = -fobjc-runtime=3Dgnustep -fobjc-default-synthesize-properties = -fdiagnostics-show-option -backend-option -vectorize-loops -o = /tmp/TGParser-KtbaOq.s -x c++ = /usr/src/lib/clang/libllvmtablegen/../../../contrib/llvm/lib/TableGen/TGPa= rser.cpp=20 >>> 1. /usr/include/c++/v1/locale:3072:48: current parser token 'init' >>> 2. /usr/include/c++/v1/locale:205:1 = : parsing namespace = 'std' >>> 3. /usr/include/c++/v1/locale:205:1 = : parsing namespace = '__1' >>> c++: error: unable to execute command: Abort trap (core dumped) >>> c++: error: clang frontend command failed due to signal (use -v to = see invocation) >>> FreeBSD clang version 3.3 (tags/RELEASE_33/final 183502) 20130610 >>> Target: armv6--freebsd10.0-gnueabi >>> Thread model: posix >>> c++: note: diagnostic msg: PLEASE submit a bug report to = http://llvm.org/bugs/ and include the crash backtrace, preprocessed = source, and associated run script. >>> c++: note: diagnostic msg: Error generating preprocessed source(s). >>> *** Error code 254 >>>=20 >>> Stop. >>> make[3]: stopped in /usr/src/lib/clang/libllvmtablegen >>> *** Error code 1 >>>=20 >>> Stop. >>> make[2]: stopped in /usr/src >>> *** Error code 1 >>>=20 >>> Stop. >>> make[1]: stopped in /usr/src >>> *** Error code 1 >>>=20 >>> Stop. >>> make: stopped in /usr/src >>>=20 >>> 2) The successful upgrade on Raspberry Pi had to be restarted a = couple of times (using -DNO_CLEAN) due to hangs. I have noticed = problems with the system when swap is used. Paging out to swap seems = okay, but processes appear to die when they are paged back in from swap. = Sometimes, this hangs the system. >>>=20 >>> 3) FWIW, I am running with super pages enabled: = vm.pmap.sp_enabled=3D1. >>>=20 >>> Cheers, >>>=20 >>> Paul. >>> _______________________________________________ >>> 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" >>=20 >=20 From owner-freebsd-arm@FreeBSD.ORG Sun Sep 15 22:48:31 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id B49189EE for ; Sun, 15 Sep 2013 22:48:31 +0000 (UTC) (envelope-from paul@gromit.dlib.vt.edu) Received: from lennier.cc.vt.edu (lennier.cc.vt.edu [198.82.162.213]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 728762A30 for ; Sun, 15 Sep 2013 22:48:31 +0000 (UTC) Received: from mr2.cc.vt.edu (mr2.cc.vt.edu [198.82.163.74]) by lennier.cc.vt.edu (8.13.8/8.13.8) with ESMTP id r8FMlTrT020723; Sun, 15 Sep 2013 18:47:29 -0400 Received: from auth1.smtp.vt.edu (auth1.smtp.vt.edu [198.82.161.152]) by mr2.cc.vt.edu (8.14.4/8.14.4) with ESMTP id r8FMlTKd023271; Sun, 15 Sep 2013 18:47:29 -0400 Received: from gromit.chumby.lan (c-98-249-9-133.hsd1.va.comcast.net [98.249.9.133]) (authenticated bits=0) by auth1.smtp.vt.edu (8.14.4/8.14.4) with ESMTP id r8FMlSei003170 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 15 Sep 2013 18:47:29 -0400 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Subject: Re: A successful native build using clang at last---just! From: Paul Mather In-Reply-To: <144C741C-550E-4874-9F10-093959204270@bsdimp.com> Date: Sun, 15 Sep 2013 18:47:28 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <621E74E9-602E-4005-B418-480C183B9D6D@gromit.dlib.vt.edu> References: <581873CA-BFB9-4287-9DFE-46A262B4459A@gromit.dlib.vt.edu> <48D945AB-1303-4ECB-9250-1DEA548FAECA@gromit.dlib.vt.edu> <144C741C-550E-4874-9F10-093959204270@bsdimp.com> To: Warner Losh X-Mailer: Apple Mail (2.1508) Cc: freebsd-arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Sep 2013 22:48:31 -0000 On Sep 15, 2013, at 6:02 PM, Warner Losh wrote: >=20 > On Sep 15, 2013, at 3:52 PM, Paul Mather wrote: >=20 >> On Sep 15, 2013, at 5:34 PM, Warner Losh wrote: >>=20 >>> Do you have swap space configured? clang building clang takes a lot = of memory... >>=20 >> Yes, I have swap space configured (see item 2 below). It's on an = external USB drive (as are /usr/src and /usr/obj), and the swap = partition is 2 GB in size. >=20 > 2GB might not be enough... I always configure 6GB of swap, but I use = a sparse zerod file to do it. Might be worth a shot... True, it's worth a shot. I'll try adding more swap space, but I doubt = it will help. Looking at swap usage during the build, it never seems to = consume more than a few MB of swap, and has never come anywhere near = using the 2 GB that is already configured. It's odd, too, that 2 GB swap is enough to complete a native build on a = Raspberry Pi Model B and not a BeagleBone Black (both 512 MB RAM = systems). Also, as noted, processes appear to die when memory used by them is = paged back in, so I'm wondering if there's a bug in swap handling on = FreeBSD/arm to blame? Cheers, Paul. >=20 >> Note, this is a native build. I don't have problems cross-building = FreeBSD/arm using Crochet on FreeBSD/amd64. >=20 > Yea, amd64 machine likely has lots of memory... >=20 > Warner >=20 >> Cheers, >>=20 >> Paul. >>=20 >>>=20 >>> Warner >>>=20 >>>=20 >>> On Sep 15, 2013, at 3:19 PM, Paul Mather wrote: >>>=20 >>>> After quite a bit of trying, I finally was able to complete a = native build and upgrade using clang on FreeBSD/arm. I used r255420 as = the build platform and was able to upgrade to r255586 on my Raspberry = Pi. >>>>=20 >>>> Here are some observations: >>>>=20 >>>> 1) For some reason this same upgrade failed on my BeagleBone Black = (also running r255420). It fails early on with this error and doesn't = get past it: >>>>=20 >>>> [[...]] >>>> c++ -O -pipe = -I/usr/src/lib/clang/libllvmtablegen/../../../contrib/llvm/include = -I/usr/src/lib/clang/libllvmtablegen/../../../contrib/llvm/tools/clang/inc= lude = -I/usr/src/lib/clang/libllvmtablegen/../../../contrib/llvm/lib/TableGen = -I. = -I/usr/src/lib/clang/libllvmtablegen/../../../contrib/llvm/../../lib/clang= /include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS = -D__STDC_CONSTANT_MACROS -fno-strict-aliasing = -DLLVM_DEFAULT_TARGET_TRIPLE=3D\"armv6-gnueabi-freebsd10.0\" = -DLLVM_HOST_TRIPLE=3D\"armv6-unknown-freebsd10.0\" = -DDEFAULT_SYSROOT=3D\"\" -I/usr/obj/usr/src/tmp/legacy/usr/include = -Wno-c++11-extensions -fno-exceptions -fno-rtti -c = /usr/src/lib/clang/libllvmtablegen/../../../contrib/llvm/lib/TableGen/TGPa= rser.cpp -o TGParser.o >>>> Assertion failed: (!FoundVal && "Key already in new map?"), = function moveFromOldBuckets, file = /usr/src/lib/clang/libclangast/../../../contrib/llvm/include/llvm/ADT/Dens= eMap.h, line 289. >>>> Stack dump: >>>> 0. Program arguments: /usr/bin/c++ -cc1 -triple = armv6--freebsd10.0-gnueabi -S -disable-free -main-file-name TGParser.cpp = -mrelocation-model static -mdisable-fp-elim -relaxed-aliasing = -mconstructor-aliases -target-abi aapcs-linux -target-cpu arm1136jf-s = -msoft-float -mfloat-abi soft -target-feature +soft-float = -target-feature +soft-float-abi -target-feature -neon -coverage-file = /tmp/TGParser-KtbaOq.s -resource-dir /usr/bin/../lib/clang/3.3 -D = LLVM_ON_UNIX -D LLVM_ON_FREEBSD -D __STDC_LIMIT_MACROS -D = __STDC_CONSTANT_MACROS -D = LLVM_DEFAULT_TARGET_TRIPLE=3D"armv6-gnueabi-freebsd10.0" -D = LLVM_HOST_TRIPLE=3D"armv6-unknown-freebsd10.0" -D DEFAULT_SYSROOT=3D"" = -I /usr/src/lib/clang/libllvmtablegen/../../../contrib/llvm/include -I = /usr/src/lib/clang/libllvmtablegen/../../../contrib/llvm/tools/clang/inclu= de -I = /usr/src/lib/clang/libllvmtablegen/../../../contrib/llvm/lib/TableGen -I = . -I = /usr/src/lib/clang/libllvmtablegen/../../../contrib/llvm/../../lib/clang/i= nclude -I /usr/obj/usr/src/tmp/l >>>> egacy/usr/include -internal-isystem /usr/include/c++/v1 -O2 = -Wno-c++11-extensions -fdeprecated-macro -fno-dwarf-directory-asm = -fdebug-compilation-dir = /usr/obj/usr/src/tmp/usr/src/lib/clang/libllvmtablegen -ferror-limit 19 = -fmessage-length 0 -mstackrealign -fno-rtti -fno-signed-char = -fobjc-runtime=3Dgnustep -fobjc-default-synthesize-properties = -fdiagnostics-show-option -backend-option -vectorize-loops -o = /tmp/TGParser-KtbaOq.s -x c++ = /usr/src/lib/clang/libllvmtablegen/../../../contrib/llvm/lib/TableGen/TGPa= rser.cpp=20 >>>> 1. /usr/include/c++/v1/locale:3072:48: current parser token 'init' >>>> 2. /usr/include/c++/v1/locale:205:1 = : parsing namespace = 'std' >>>> 3. /usr/include/c++/v1/locale:205:1 = : parsing namespace = '__1' >>>> c++: error: unable to execute command: Abort trap (core dumped) >>>> c++: error: clang frontend command failed due to signal (use -v to = see invocation) >>>> FreeBSD clang version 3.3 (tags/RELEASE_33/final 183502) 20130610 >>>> Target: armv6--freebsd10.0-gnueabi >>>> Thread model: posix >>>> c++: note: diagnostic msg: PLEASE submit a bug report to = http://llvm.org/bugs/ and include the crash backtrace, preprocessed = source, and associated run script. >>>> c++: note: diagnostic msg: Error generating preprocessed source(s). >>>> *** Error code 254 >>>>=20 >>>> Stop. >>>> make[3]: stopped in /usr/src/lib/clang/libllvmtablegen >>>> *** Error code 1 >>>>=20 >>>> Stop. >>>> make[2]: stopped in /usr/src >>>> *** Error code 1 >>>>=20 >>>> Stop. >>>> make[1]: stopped in /usr/src >>>> *** Error code 1 >>>>=20 >>>> Stop. >>>> make: stopped in /usr/src >>>>=20 >>>> 2) The successful upgrade on Raspberry Pi had to be restarted a = couple of times (using -DNO_CLEAN) due to hangs. I have noticed = problems with the system when swap is used. Paging out to swap seems = okay, but processes appear to die when they are paged back in from swap. = Sometimes, this hangs the system. >>>>=20 >>>> 3) FWIW, I am running with super pages enabled: = vm.pmap.sp_enabled=3D1. >>>>=20 >>>> Cheers, >>>>=20 >>>> Paul. >>>> _______________________________________________ >>>> 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" >>>=20 >>=20 >=20 From owner-freebsd-arm@FreeBSD.ORG Mon Sep 16 01:26:40 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id CA64E19B; Mon, 16 Sep 2013 01:26:40 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wg0-x230.google.com (mail-wg0-x230.google.com [IPv6:2a00:1450:400c:c00::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 1E6D321B2; Mon, 16 Sep 2013 01:26:39 +0000 (UTC) Received: by mail-wg0-f48.google.com with SMTP id n12so3065543wgh.27 for ; Sun, 15 Sep 2013 18:26:38 -0700 (PDT) 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=Q5h6CGlyU1KJOfkT54S7D5NYrHN4O8QOte48foSVLhM=; b=A+6ZKmAkQ3NVXw9cYd4r2/Way5vwCBQwVm1MyMKU24vEOQfVonIQr2K8z8471Hh7Lg Pqg3yh0TYVs6F3pRekO6fij61SYUVu5/TWTQ4pHnBUekCLEx2rXYh7Z6mqW6pukGaKiR VCnGDtcNd4ZfKmSTZ2SK/LOgr/FJ4TcNx+WtkZBLHxmyp6+l8Nsv+l3dA3/82E6HH2rl N5Fc8BhcboWaYmtV7ek2DH3lulwhapsRibnTTlmbAxHYcT2Od7xysqk9v18J6ChiXAeh Hy0xRn/ybJHNSnURxvvkL372rWGlw5qJLCXMXq3GhMef6wO22qfTI/iQUY65RFbEHUmf bgCQ== MIME-Version: 1.0 X-Received: by 10.180.87.38 with SMTP id u6mr11503470wiz.0.1379294798510; Sun, 15 Sep 2013 18:26:38 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.216.73.133 with HTTP; Sun, 15 Sep 2013 18:26:38 -0700 (PDT) In-Reply-To: <5236236E.5060502@freebsd.org> References: <522F346D.9000609@freebsd.org> <1378826132.1111.592.camel@revolution.hippie.lan> <5236236E.5060502@freebsd.org> Date: Sun, 15 Sep 2013 18:26:38 -0700 X-Google-Sender-Auth: PGPyfhso7or0oyE4VBH5xusul5Q Message-ID: Subject: Re: AVILA kernel From: Adrian Chadd To: Nathan Whitehorn Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: "freebsd-arm@freebsd.org" , Ian Lepore X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Sep 2013 01:26:40 -0000 On 15 September 2013 14:15, Nathan Whitehorn wrote: > This is what I get. Symbols aren't loaded, so I'm not really sure how > useful it is in the end. > > The configuration in question is a modified one. The stock AVILA > configuration gives the highly suspicious: > panic: mtx_lock() of spin mutex pmap @ /usr/src/sys/arm/arm/pmap.c:**3676 > .. hm, how about bumping that to kib/alc? There's been VM changes that the sys/arm/arm/ pmap code may not have been updated for. -adrian From owner-freebsd-arm@FreeBSD.ORG Mon Sep 16 11:06:41 2013 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id C2F4CBA7 for ; Mon, 16 Sep 2013 11:06:41 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 96CF32148 for ; Mon, 16 Sep 2013 11:06:41 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r8GB6fOw089547 for ; Mon, 16 Sep 2013 11:06:41 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r8GB6fbC089545 for freebsd-arm@FreeBSD.org; Mon, 16 Sep 2013 11:06:41 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 16 Sep 2013 11:06:41 GMT Message-Id: <201309161106.r8GB6fbC089545@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-arm@FreeBSD.org Subject: Current problem reports assigned to freebsd-arm@FreeBSD.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Sep 2013 11:06:41 -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/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/175605 arm please fix build binutils-2.23.1 in raspberry pi o arm/173617 arm Dreamplug exhibits eSATA file corruption using network o kern/171096 arm [arm][xscale][ixp]Allow 16bit access on PCI bus o arm/166256 arm build fail in pmap.c o arm/162159 arm [panic] USB errors leading to panic on DockStar 9.0-RC o arm/161110 arm /usr/src/sys/arm/include/signal.h is bad o arm/161044 arm devel/icu does not build on arm o arm/158950 arm arm/sheevaplug fails fsx when mmap operations are enab o arm/155894 arm [patch] Enable at91 booting from SDHC (high capacity) p arm/155214 arm [patch] MMC/SD IO slow on Atmel ARM with modern large o arm/154227 arm [geli] using GELI leads to panic on ARM o arm/153380 arm Panic / translation fault with wlan on ARM o arm/150581 arm [irq] Unknown error generates IRQ address decoding err o arm/134368 arm [new driver] [patch] nslu2_led driver for the LEDs on 27 problems total. From owner-freebsd-arm@FreeBSD.ORG Mon Sep 16 14:03:15 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 43312614 for ; Mon, 16 Sep 2013 14:03:15 +0000 (UTC) (envelope-from paul@gromit.dlib.vt.edu) Received: from lennier.cc.vt.edu (lennier.cc.vt.edu [198.82.162.213]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id DC2A52F88 for ; Mon, 16 Sep 2013 14:03:14 +0000 (UTC) Received: from mr2.cc.vt.edu (mr2.cc.vt.edu [198.82.163.74]) by lennier.cc.vt.edu (8.13.8/8.13.8) with ESMTP id r8GE2Dov015344; Mon, 16 Sep 2013 10:02:13 -0400 Received: from auth1.smtp.vt.edu (auth1.smtp.vt.edu [198.82.161.152]) by mr2.cc.vt.edu (8.14.4/8.14.4) with ESMTP id r8GE2CdL022550; Mon, 16 Sep 2013 10:02:13 -0400 Received: from pmather.tower.lib.vt.edu (pmather.tower.lib.vt.edu [128.173.51.28]) (authenticated bits=0) by auth1.smtp.vt.edu (8.14.4/8.14.4) with ESMTP id r8GE2CeO031020 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 16 Sep 2013 10:02:12 -0400 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Subject: Re: A successful native build using clang at last---just! From: Paul Mather In-Reply-To: <144C741C-550E-4874-9F10-093959204270@bsdimp.com> Date: Mon, 16 Sep 2013 10:02:12 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <581873CA-BFB9-4287-9DFE-46A262B4459A@gromit.dlib.vt.edu> <48D945AB-1303-4ECB-9250-1DEA548FAECA@gromit.dlib.vt.edu> <144C741C-550E-4874-9F10-093959204270@bsdimp.com> To: Warner Losh X-Mailer: Apple Mail (2.1508) Cc: freebsd-arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Sep 2013 14:03:15 -0000 On Sep 15, 2013, at 6:02 PM, Warner Losh wrote: >=20 > On Sep 15, 2013, at 3:52 PM, Paul Mather wrote: >=20 >> On Sep 15, 2013, at 5:34 PM, Warner Losh wrote: >>=20 >>> Do you have swap space configured? clang building clang takes a lot = of memory... >>=20 >> Yes, I have swap space configured (see item 2 below). It's on an = external USB drive (as are /usr/src and /usr/obj), and the swap = partition is 2 GB in size. >=20 > 2GB might not be enough... I always configure 6GB of swap, but I use = a sparse zerod file to do it. Might be worth a shot... I increased the amount of swap to 6 GB and also moved /tmp from a = swap-backed md-device to its own UFS file system on the external USB = hard drive I'm using, but I still get an error when doing "make = buildkernel": =3D=3D=3D=3D=3D [[...]] cc -c -O -pipe -std=3Dc99 -g -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/usr/src/sys = -I/usr/src/sys/contrib/altq -I/usr/src/sys/contrib/libfdt -D_KERNEL = -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -funwind-tables = -mllvm -arm-enable-ehabi -ffreestanding -Werror = /usr/src/sys/fs/nfsclient/nfs_clsubs.c cc -c -O -pipe -std=3Dc99 -g -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/usr/src/sys = -I/usr/src/sys/contrib/altq -I/usr/src/sys/contrib/libfdt -D_KERNEL = -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -funwind-tables = -mllvm -arm-enable-ehabi -ffreestanding -Werror = /usr/src/sys/fs/nfsclient/nfs_clstate.c Stack dump: 0. Program arguments: /usr/obj/usr/src/tmp/usr/bin/cc -cc1 -triple = armv6--freebsd10.0-gnueabi -S -disable-free -main-file-name = nfs_clstate.c -mrelocation-model static -mdisable-fp-elim = -mconstructor-aliases -munwind-tables -target-abi aapcs-linux = -target-cpu arm1136jf-s -msoft-float -mfloat-abi soft -target-feature = +soft-float -target-feature +soft-float-abi -target-feature -neon -g = -coverage-file /tmp/nfs_clstate-O8Eo9U.s -nostdsysteminc -nobuiltininc = -resource-dir /usr/obj/usr/src/tmp/usr/bin/../lib/clang/3.3 -include = opt_global.h -D _KERNEL -D HAVE_KERNEL_OPTION_HEADERS -I . -I = /usr/src/sys -I /usr/src/sys/contrib/altq -I /usr/src/sys/contrib/libfdt = -isysroot /usr/obj/usr/src/tmp -O2 -Wall -Wredundant-decls = -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes = -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign = -Wmissing-include-dirs -Wno-error-tautological-compare = -Wno-error-empty-body -Wno-error-parentheses-equality -Werror -std=3Dc99 = -fno-dwarf-directory-asm -fdebug-compilation-dir = /usr/obj/usr/src/sys/BEAGLEBONE -ferror-limit 19 -fmessage-length 0 = -ffreestanding -fformat-extensions -mstackrealign -fno-signed-char = -fobjc-runtime=3Dgnustep -fobjc-default-synthesize-properties = -fdiagnostics-show-option -backend-option -vectorize-loops -mllvm = -arm-enable-ehabi -o /tmp/nfs_clstate-O8Eo9U.s -x c = /usr/src/sys/fs/nfsclient/nfs_clstate.c=20 1. /usr/src/sys/fs/nfsclient/nfs_clstate.c:608:1: current parser = token 'static' 2. /usr/src/sys/fs/nfsclient/nfs_clstate.c:476:1: parsing function = body 'nfscl_getstateid' error: unable to rename temporary '/tmp/nfs_clstate-O8Eo9U.s-2f4669b4' = to output file '/tmp/nfs_clstate-O8Eo9U.s': 'No such file or directory' 1 error generated. *** Error code 1 Stop. make[2]: stopped in /usr/obj/usr/src/sys/BEAGLEBONE *** Error code 1 Stop. make[1]: stopped in /usr/src *** Error code 1 Stop. make: stopped in /usr/src =3D=3D=3D=3D=3D The USB hard drive I'm using has its own power supply, and I'm using a = 5V 2A power supply with the BeagleBone Black, so I don't think this = error is due to flaky power instability. I've never seen the above error before, and it doesn't make much sense = to me. I'm going to try and see if I can build the BEAGLEBONE kernel = natively on my Raspberry Pi, next. Failing that, it'll have to be = another Crochet image for my BeagleBone Black. Cheers, Paul. >=20 >> Note, this is a native build. I don't have problems cross-building = FreeBSD/arm using Crochet on FreeBSD/amd64. >=20 > Yea, amd64 machine likely has lots of memory... >=20 > Warner >=20 >> Cheers, >>=20 >> Paul. >>=20 >>>=20 >>> Warner >>>=20 >>>=20 >>> On Sep 15, 2013, at 3:19 PM, Paul Mather wrote: >>>=20 >>>> After quite a bit of trying, I finally was able to complete a = native build and upgrade using clang on FreeBSD/arm. I used r255420 as = the build platform and was able to upgrade to r255586 on my Raspberry = Pi. >>>>=20 >>>> Here are some observations: >>>>=20 >>>> 1) For some reason this same upgrade failed on my BeagleBone Black = (also running r255420). It fails early on with this error and doesn't = get past it: >>>>=20 >>>> [[...]] >>>> c++ -O -pipe = -I/usr/src/lib/clang/libllvmtablegen/../../../contrib/llvm/include = -I/usr/src/lib/clang/libllvmtablegen/../../../contrib/llvm/tools/clang/inc= lude = -I/usr/src/lib/clang/libllvmtablegen/../../../contrib/llvm/lib/TableGen = -I. = -I/usr/src/lib/clang/libllvmtablegen/../../../contrib/llvm/../../lib/clang= /include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS = -D__STDC_CONSTANT_MACROS -fno-strict-aliasing = -DLLVM_DEFAULT_TARGET_TRIPLE=3D\"armv6-gnueabi-freebsd10.0\" = -DLLVM_HOST_TRIPLE=3D\"armv6-unknown-freebsd10.0\" = -DDEFAULT_SYSROOT=3D\"\" -I/usr/obj/usr/src/tmp/legacy/usr/include = -Wno-c++11-extensions -fno-exceptions -fno-rtti -c = /usr/src/lib/clang/libllvmtablegen/../../../contrib/llvm/lib/TableGen/TGPa= rser.cpp -o TGParser.o >>>> Assertion failed: (!FoundVal && "Key already in new map?"), = function moveFromOldBuckets, file = /usr/src/lib/clang/libclangast/../../../contrib/llvm/include/llvm/ADT/Dens= eMap.h, line 289. >>>> Stack dump: >>>> 0. Program arguments: /usr/bin/c++ -cc1 -triple = armv6--freebsd10.0-gnueabi -S -disable-free -main-file-name TGParser.cpp = -mrelocation-model static -mdisable-fp-elim -relaxed-aliasing = -mconstructor-aliases -target-abi aapcs-linux -target-cpu arm1136jf-s = -msoft-float -mfloat-abi soft -target-feature +soft-float = -target-feature +soft-float-abi -target-feature -neon -coverage-file = /tmp/TGParser-KtbaOq.s -resource-dir /usr/bin/../lib/clang/3.3 -D = LLVM_ON_UNIX -D LLVM_ON_FREEBSD -D __STDC_LIMIT_MACROS -D = __STDC_CONSTANT_MACROS -D = LLVM_DEFAULT_TARGET_TRIPLE=3D"armv6-gnueabi-freebsd10.0" -D = LLVM_HOST_TRIPLE=3D"armv6-unknown-freebsd10.0" -D DEFAULT_SYSROOT=3D"" = -I /usr/src/lib/clang/libllvmtablegen/../../../contrib/llvm/include -I = /usr/src/lib/clang/libllvmtablegen/../../../contrib/llvm/tools/clang/inclu= de -I = /usr/src/lib/clang/libllvmtablegen/../../../contrib/llvm/lib/TableGen -I = . -I = /usr/src/lib/clang/libllvmtablegen/../../../contrib/llvm/../../lib/clang/i= nclude -I /usr/obj/usr/src/tmp/l >>>> egacy/usr/include -internal-isystem /usr/include/c++/v1 -O2 = -Wno-c++11-extensions -fdeprecated-macro -fno-dwarf-directory-asm = -fdebug-compilation-dir = /usr/obj/usr/src/tmp/usr/src/lib/clang/libllvmtablegen -ferror-limit 19 = -fmessage-length 0 -mstackrealign -fno-rtti -fno-signed-char = -fobjc-runtime=3Dgnustep -fobjc-default-synthesize-properties = -fdiagnostics-show-option -backend-option -vectorize-loops -o = /tmp/TGParser-KtbaOq.s -x c++ = /usr/src/lib/clang/libllvmtablegen/../../../contrib/llvm/lib/TableGen/TGPa= rser.cpp=20 >>>> 1. /usr/include/c++/v1/locale:3072:48: current parser token 'init' >>>> 2. /usr/include/c++/v1/locale:205:1 = : parsing namespace = 'std' >>>> 3. /usr/include/c++/v1/locale:205:1 = : parsing namespace = '__1' >>>> c++: error: unable to execute command: Abort trap (core dumped) >>>> c++: error: clang frontend command failed due to signal (use -v to = see invocation) >>>> FreeBSD clang version 3.3 (tags/RELEASE_33/final 183502) 20130610 >>>> Target: armv6--freebsd10.0-gnueabi >>>> Thread model: posix >>>> c++: note: diagnostic msg: PLEASE submit a bug report to = http://llvm.org/bugs/ and include the crash backtrace, preprocessed = source, and associated run script. >>>> c++: note: diagnostic msg: Error generating preprocessed source(s). >>>> *** Error code 254 >>>>=20 >>>> Stop. >>>> make[3]: stopped in /usr/src/lib/clang/libllvmtablegen >>>> *** Error code 1 >>>>=20 >>>> Stop. >>>> make[2]: stopped in /usr/src >>>> *** Error code 1 >>>>=20 >>>> Stop. >>>> make[1]: stopped in /usr/src >>>> *** Error code 1 >>>>=20 >>>> Stop. >>>> make: stopped in /usr/src >>>>=20 >>>> 2) The successful upgrade on Raspberry Pi had to be restarted a = couple of times (using -DNO_CLEAN) due to hangs. I have noticed = problems with the system when swap is used. Paging out to swap seems = okay, but processes appear to die when they are paged back in from swap. = Sometimes, this hangs the system. >>>>=20 >>>> 3) FWIW, I am running with super pages enabled: = vm.pmap.sp_enabled=3D1. >>>>=20 >>>> Cheers, >>>>=20 >>>> Paul. >>>> _______________________________________________ >>>> 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" >>>=20 >>=20 >=20 From owner-freebsd-arm@FreeBSD.ORG Mon Sep 16 14:24:33 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id D4FDCF30 for ; Mon, 16 Sep 2013 14:24:33 +0000 (UTC) (envelope-from krister.olofsson@gmail.com) Received: from mail-ie0-x229.google.com (mail-ie0-x229.google.com [IPv6:2607:f8b0:4001: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 A8EE6212E for ; Mon, 16 Sep 2013 14:24:33 +0000 (UTC) Received: by mail-ie0-f169.google.com with SMTP id tp5so7514660ieb.14 for ; Mon, 16 Sep 2013 07:24:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=Mvc8UB+uoYRhB2fX6gPvVJbrSZBqLj9Mno10KRl77jI=; b=X8gQtsDumEBs3sa5D2KwrQVx4NSB/c+v9OLrz3Tm0Jnx0LbOZu4fYTl9TeTcZPsjBW dO/AiHrN7nHU6Xc+CUC+Gz1KEVC7jNPdR3tBQJx+mvVCzY8wrfU4a49yLw4Arc/qtlIp NDgpZXMDtJZRvfjWqe9lpfECPSo58NC4aApvFMHDav7eNHC7ZZ0ARM3chkW69xxudZBM +kTXEPlMOCMgAsTyuOYRL73HGL/ojoT0UETyH+pjNd6yZsqwtoUJ8PBNRgH2SMZl5GYa E+KZCaTEyj1TftrdSHaUaVrBby4Rfxt8jPMujtIl7DPyf3DmSuBJmmFABKu3VB78pIRb To4Q== MIME-Version: 1.0 X-Received: by 10.43.143.133 with SMTP id jm5mr828856icc.25.1379341473018; Mon, 16 Sep 2013 07:24:33 -0700 (PDT) Received: by 10.64.231.67 with HTTP; Mon, 16 Sep 2013 07:24:32 -0700 (PDT) Date: Mon, 16 Sep 2013 16:24:32 +0200 Message-ID: Subject: gdb not working in variadic functions From: Krister Olofsson To: freebsd-arm@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Sep 2013 14:24:33 -0000 I'm working with a board with FreeBSD 8.2 on Marvell MV78100 (Discovery SOC) - an ARMv5TE and having problem with gdb in variadic functions. gdb does not show the correct values of the variables. The program executes correctly, it's just problems with gdb. See example and source code below. Why isn't the variable n=2? Any clues? //Krister su# gcc -v Using built-in specs. Target: arm-undermydesk-freebsd Configured with: FreeBSD/arm system compiler Thread model: posix gcc version 4.2.1 20070719 [FreeBSD] su# gcc main.c -O0 -g -o debug_test su# gdb debug_test GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "arm-marcel-freebsd"... (gdb) b main Breakpoint 1 at 0x8518: file main.c, line 8. (gdb) run Starting program: /usr/home/dev/debug_test Breakpoint 1, main () at main.c:8 8 printf("Sum of 15 and 56 = %d\n", sum(2, 15, 56) ); (gdb) s sum (n=-1073746756) at main.c:18 18 va_start(ap, n); (gdb) p n $1 = -1073746756 (gdb) frame #0 sum (n=-1073746756) at main.c:18 18 va_start(ap, n); (gdb) n 19 for(i = 0; i < n; i++) (gdb) p n $2 = -1073746756 (gdb) //main.c #include #include int sum(int, ...); int main() { printf("Sum of 15 and 56 = %d\n", sum(2, 15, 56) ); return 0; } int sum(int n, ...) { int val = 0; va_list ap; int i; va_start(ap, n); for(i = 0; i < n; i++) { val += va_arg(ap, int); } va_end(ap); return val; } From owner-freebsd-arm@FreeBSD.ORG Mon Sep 16 19:50:07 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 61EF44C2; Mon, 16 Sep 2013 19:50:07 +0000 (UTC) (envelope-from mattia.rossi.mate@gmail.com) Received: from mail-we0-x232.google.com (mail-we0-x232.google.com [IPv6:2a00:1450:400c:c03::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id A84AD28A4; Mon, 16 Sep 2013 19:50:06 +0000 (UTC) Received: by mail-we0-f178.google.com with SMTP id u57so4225587wes.9 for ; Mon, 16 Sep 2013 12:50:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:reply-to:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=llm3jn5eUkdWQ3piInCxyEe67wPyt5/WqWFP4ZuhDmw=; b=binydf7tjz/RFZYrPHBliKifLixCS54ohoM/F6Flh/6S8tQfUrGvs5VOxK14cIoUAx 5hJXTfnHB19o7Sovf0gLyJAsqHWinH7C9nnGOtV4h6bR5XaVx796GRZZ3wKOGTnJb3ae RJvzm7qBSmqqLtb8/1hxt3RwTio+oAprmtHZqxAz1fkfFD5yS9VzoNUyfXSJwiK7Rf9B +zp2df0qPRWp5RTZHf4eeIKI45NZG4tsNsqnSOGIoCWe2KRgFv1Wc/bXhWEtypfmNd9e G9ymEAQqsgpfqxyG7WAjddv9cfzSCFKWEeYPyZ7N2/ROChzvLSIpzfsSCUIpT6hMnqGi rnPg== X-Received: by 10.180.106.40 with SMTP id gr8mr14830718wib.11.1379361004989; Mon, 16 Sep 2013 12:50:04 -0700 (PDT) Received: from [192.168.0.10] (46-126-92-160.dynamic.hispeed.ch. [46.126.92.160]) by mx.google.com with ESMTPSA id u15sm17682737wib.5.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 16 Sep 2013 12:50:03 -0700 (PDT) Message-ID: <523760EA.7090306@gmail.com> Date: Mon, 16 Sep 2013 21:50:02 +0200 From: Mattia Rossi User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: freebsd-arm@freebsd.org, freebsd-current@freebsd.org, freebsd-ports@freebsd.org Subject: Installing ports without info files Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: mattia.rossi.mate@gmail.com List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Sep 2013 19:50:07 -0000 Hi all, I've build a world with the following constraints: -DWITHOUT_INFO -DWITHOUT_MAN -DWITHOUT_SHAREDOCS -DWITHOUT_EXAMPLES -DWITHOUT_HTML as I don't need that stuff. Turns out, this prevents tools like install-info being built. Now trying to build devel/gettext I can't get it installed, as it always wants to install info files using install-info, which of course fails. How do I tell the system not to build info files (or manpages or all of the stuff above I don't want in the first place) when building ports? I've tried with "make -DWITHOUT_INFO install" as well as with putting WITHOUT_INFO=yes in make.conf. Gettext will still fail to install. Is this a gettext problem? Or a generic ports problem? I'm running current on arm (thanks again to freebsd-arm people for fixing it): FreeBSD dreamplug 10.0-ALPHA1 FreeBSD 10.0-ALPHA1 #15 r255499M: It's also not possible to "make index" for INDEX-10 if you use a stripped-down ports tree (none of the language ports), as there are some dependencies in the tree to french (cad-astk) and russian (stardict-*) which obviously can't be resolved. Help is appreciated! Cheers, Mat From owner-freebsd-arm@FreeBSD.ORG Mon Sep 16 20:53:42 2013 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 7FB723CF; Mon, 16 Sep 2013 20:53:42 +0000 (UTC) (envelope-from ian@FreeBSD.org) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 550522C9F; Mon, 16 Sep 2013 20:53:42 +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 1VLfnh-000LQv-1N; Mon, 16 Sep 2013 20:53:41 +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 r8GKrc1v012968; Mon, 16 Sep 2013 14:53:38 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1805xRhNHL02DGkXaEqj+jT Subject: Re: Installing ports without info files From: Ian Lepore To: mattia.rossi.mate@gmail.com In-Reply-To: <523760EA.7090306@gmail.com> References: <523760EA.7090306@gmail.com> Content-Type: text/plain; charset="us-ascii" Date: Mon, 16 Sep 2013 14:53:37 -0600 Message-ID: <1379364817.1197.45.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, freebsd-current@FreeBSD.org, freebsd-ports@FreeBSD.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Sep 2013 20:53:42 -0000 On Mon, 2013-09-16 at 21:50 +0200, Mattia Rossi wrote: > Hi all, > > I've build a world with the following constraints: -DWITHOUT_INFO > -DWITHOUT_MAN -DWITHOUT_SHAREDOCS -DWITHOUT_EXAMPLES -DWITHOUT_HTML > > as I don't need that stuff. Turns out, this prevents tools like > install-info being built. > Now trying to build devel/gettext I can't get it installed, as it always > wants to install info files using install-info, which of course fails. > > How do I tell the system not to build info files (or manpages or all of > the stuff above I don't want in the first place) when building ports? > > I've tried with "make -DWITHOUT_INFO install" as well as with putting > WITHOUT_INFO=yes in make.conf. > > Gettext will still fail to install. > Is this a gettext problem? Or a generic ports problem? > > I'm running current on arm (thanks again to freebsd-arm people for > fixing it): > FreeBSD dreamplug 10.0-ALPHA1 FreeBSD 10.0-ALPHA1 #15 r255499M: > > It's also not possible to "make index" for INDEX-10 if you use a > stripped-down ports tree (none of the language ports), as there are some > dependencies in the tree to french (cad-astk) and russian (stardict-*) > which obviously can't be resolved. > > Help is appreciated! > > Cheers, > I fought with the info problem for a few hours at $work and never got it resolved, I had to remove the WITHOUT_INFO so that the tools would be there to let ports build, and then rely on an mtree pruning script to keep the actual info files out of the filesystem image. -- Ian From owner-freebsd-arm@FreeBSD.ORG Mon Sep 16 21:00:06 2013 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 9D358A22; Mon, 16 Sep 2013 21:00:06 +0000 (UTC) (envelope-from jhein@symmetricom.com) Received: from duck.symmetricom.us (duck.symmetricom.us [206.168.13.214]) by mx1.freebsd.org (Postfix) with ESMTP id 5613D2DD7; Mon, 16 Sep 2013 21:00:06 +0000 (UTC) Received: from gromit.timing.com (gromit.timing.com [206.168.13.209]) by duck.symmetricom.us (8.14.6/8.14.6) with ESMTP id r8GKxx80004056; Mon, 16 Sep 2013 14:59:59 -0600 (MDT) (envelope-from jhein@symmetricom.com) Received: from gromit.timing.com (localhost [127.0.0.1]) by gromit.timing.com (8.14.7/8.14.5) with ESMTP id r8GKxvKG060655; Mon, 16 Sep 2013 14:59:57 -0600 (MDT) (envelope-from jhein@gromit.timing.com) Received: (from jhein@localhost) by gromit.timing.com (8.14.7/8.14.6/Submit) id r8GKxv4P060654; Mon, 16 Sep 2013 14:59:57 -0600 (MDT) (envelope-from jhein) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21047.29005.285571.326198@gromit.timing.com> Date: Mon, 16 Sep 2013 14:59:57 -0600 From: John Hein To: Ian Lepore Subject: Re: Installing ports without info files In-Reply-To: <1379364817.1197.45.camel@revolution.hippie.lan> References: <523760EA.7090306@gmail.com> <1379364817.1197.45.camel@revolution.hippie.lan> X-Mailer: VM 8.2.0b-trunk-1484 under 24.3.1 (i386-portbld-freebsd8.3) Cc: freebsd-arm@FreeBSD.org, mattia.rossi.mate@gmail.com, freebsd-ports@FreeBSD.org, freebsd-current@FreeBSD.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Sep 2013 21:00:06 -0000 Ian Lepore wrote at 14:53 -0600 on Sep 16, 2013: > On Mon, 2013-09-16 at 21:50 +0200, Mattia Rossi wrote: > > Hi all, > > > > I've build a world with the following constraints: -DWITHOUT_INFO > > -DWITHOUT_MAN -DWITHOUT_SHAREDOCS -DWITHOUT_EXAMPLES -DWITHOUT_HTML > > > > as I don't need that stuff. Turns out, this prevents tools like > > install-info being built. > > Now trying to build devel/gettext I can't get it installed, as it always > > wants to install info files using install-info, which of course fails. > > > > How do I tell the system not to build info files (or manpages or all of > > the stuff above I don't want in the first place) when building ports? > > > > I've tried with "make -DWITHOUT_INFO install" as well as with putting > > WITHOUT_INFO=yes in make.conf. > > > > Gettext will still fail to install. > > Is this a gettext problem? Or a generic ports problem? > > > > I'm running current on arm (thanks again to freebsd-arm people for > > fixing it): > > FreeBSD dreamplug 10.0-ALPHA1 FreeBSD 10.0-ALPHA1 #15 r255499M: > > > > It's also not possible to "make index" for INDEX-10 if you use a > > stripped-down ports tree (none of the language ports), as there are some > > dependencies in the tree to french (cad-astk) and russian (stardict-*) > > which obviously can't be resolved. > > > > Help is appreciated! > > > > Cheers, > > > > I fought with the info problem for a few hours at $work and never got it > resolved, I had to remove the WITHOUT_INFO so that the tools would be > there to let ports build, and then rely on an mtree pruning script to > keep the actual info files out of the filesystem image. > > -- Ian I have a patch for this that was going to go through a ports run, but stalled in the machine. I'll dig it out. From owner-freebsd-arm@FreeBSD.ORG Tue Sep 17 02:00:06 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 6D24A2CC for ; Tue, 17 Sep 2013 02:00:06 +0000 (UTC) (envelope-from taguchi.ch@gmail.com) Received: from mail-pa0-x235.google.com (mail-pa0-x235.google.com [IPv6:2607:f8b0:400e:c03::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 45CC42139 for ; Tue, 17 Sep 2013 02:00:06 +0000 (UTC) Received: by mail-pa0-f53.google.com with SMTP id lb1so6136948pab.12 for ; Mon, 16 Sep 2013 19:00:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=a28ql68jGISi+yR0IA/09R4yIWiV7cleZKSYBWvOuMM=; b=ItQ1ir3IhuHcUprMVDh80lFq5ByeLPkRcLprbSQ0Bj3Gznt2xCVsdo9/0rqnzEeXqH A4tiCwQ7DFh19YHy7j4jJZbPdEaZelXBsOUTeo3KwqPketuYunt3AtSxdm7wxkACxRM4 qWh5WO44zq+pr0Y/M0eRWHHPGEKlH6bQN5gKErxDs9eMwJ95uKxBnu8lc+MC9zIjAUWQ /p5ZwP+ZG46ExQo8Q/QyFbBQBRCegjojK8Zf9VS8jd6XscbvMKQuQbeMz3rR+j5PEFFm i9WyHuOy0F8zJeomYhiojrZ04umYHpEL+8AYhMAA78IkDuBvNmF8/czlqKrmykxI6wxO tltg== X-Received: by 10.66.65.108 with SMTP id w12mr199730pas.183.1379383205938; Mon, 16 Sep 2013 19:00:05 -0700 (PDT) Received: from [10.0.1.203] (48.178.30.125.dy.iij4u.or.jp. [125.30.178.48]) by mx.google.com with ESMTPSA id w6sm34392842pbt.32.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 16 Sep 2013 19:00:05 -0700 (PDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Subject: Re: What's the recipe? From: Chie Taguchi In-Reply-To: <5235D207.5070400@m5p.com> Date: Tue, 17 Sep 2013 11:00:02 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: <6AE316FC-8B08-4F5D-B918-7F97C8C4CB60@gmail.com> References: <522229C0.5030504@m5p.com> <5235D207.5070400@m5p.com> To: George Mitchell X-Mailer: Apple Mail (2.1508) Cc: "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Sep 2013 02:00:06 -0000 Have you tried ports/181140? C.Taguchi On 2013/09/16, at 0:28, George Mitchell wrote: > On 08/31/13 13:37, George Mitchell wrote: >> Have you built a working Raspberry Pi image recently? If so, for the >> benefit of the rest of us, could you share a few secrets? >>=20 >> 1. What system did you do the build on? If it was an i386 or amd64, >> what svn version was it built with? >=20 > Built on amd64, svn version r255361M. (Two changes: I still distrust > SCHED_ULE, and there's a patch [attached] required for the ARM xdev > build to complete.) >>=20 >> 2. What did you have in /etc/src.conf and /etc/make.conf, both for >> building the build system itself and for building the RPi? >=20 > I finally bit the bullet and went to clang. /etc/src.conf is empty; > /etc/make.conf contains "WITH_PKGNG=3Dyes". >>=20 >> 3. What svn version of /usr/src did you use in building the RPi = image? >>=20 > Same as above (r255361M). >=20 >> 4. Did you use crochet? If so, what was the last commit in your git >> log? > commit b154a2f1252eaa5f4d821439d0d9005cea94e580 > Merge: a6f4cc5 8d03c23 > Author: Tim Kientzle > Date: Sat Aug 17 12:00:52 2013 -0700 >=20 >>=20 >> When I say "working," I'm hoping for the ability to run stably for a >> number of days, running NFS and CUPS. I've been doing this since >> January with a precompiled image I downloaded then which worked >> wonderfully with one of my printers, but not the other one. Now >> there's a patch that enables both printers to work, and I would love >> to build a new image. So I've been thrashing around trying to find >> the answers to the questions above without success. Thanks for any >> help you can give! -- George >=20 > This build is marginally stable. I've been working for a week to get > a complete build of print/cups and I'm not quite there. =46rom the = RPi, > /usr/ports is an NFS mount from another machine with version 326306 of > the ports tree (just before the iconv incident). The RPi likes to get > messages of this sort: >=20 > http://www.m5p.com/~george/pi/DSCN1282.JPG >=20 > primarily during the period that portmaster is discovering everybody's > dependencies. (Oddly, if I make it to the build stage, the build > completes about 90% of the time. devel/glib20 built, including its > dependencies on perl and python, in one overnight session.) >=20 > Once, instead of the fatal kernel mode prefetch abort, I got: >=20 > panic: __rw_wlock_hard: recursing but non-recursive rw pmap pw @ = /usr/src/sys/arm/arm/pmap-v6.c:1406 > KDB: enter: panic [ thread pid 906 tid 100076 ] > stopped at $d: ldrb r15, [r15, 15, ror r15] >=20 > (Sorry for the transcription by hand; I have an AdaFruit serial cable > on order.) >=20 > My current problem is that x11/pixman fails to build: >=20 > =3D=3D=3D> Building for pixman-0.30.0 > /usr/bin/make all-recursive > Making all in pixman > CC pixman.lo > CC pixman-access.lo > CC pixman-access-accessors.lo > CC pixman-bits-image.lo > CC pixman-combine32.lo > CC pixman-combine-float.lo > CC pixman-conical-gradient.lo > CC pixman-filter.lo > CC pixman-x86.lo > CC pixman-mips.lo > CC pixman-arm.lo > CC pixman-ppc.lo > CC pixman-edge.lo > CC pixman-edge-accessors.lo > CC pixman-fast-path.lo > CC pixman-glyph.lo > CC pixman-general.lo > CC pixman-gradient-walker.lo > CC pixman-image.lo > CC pixman-implementation.lo > pixman-implementation.c:124:38: warning: comparison of constant 64 = with expression of type 'const pixman_op_t' is always false = [-Wtautological-constant-out-of-range-compare] > if ((info->op =3D=3D op || info->op =3D=3D PIXMAN_OP_any) = && > ~~~~~~~~ ^ ~~~~~~~~~~~~~ > 1 warning generated. > CC pixman-linear-gradient.lo > CC pixman-matrix.lo > CC pixman-noop.lo > CC pixman-radial-gradient.lo > CC pixman-region16.lo > CC pixman-region32.lo > CC pixman-solid-fill.lo > CC pixman-timer.lo > CC pixman-trap.lo > CC pixman-utils.lo > CC pixman-arm-neon.lo > CPPAS pixman-arm-neon-asm.lo > /usr/include/float.h: Assembler messages: > /usr/include/float.h:43: Error: bad instruction `extern int = __flt_rounds(void)' > ./pixman-arm-neon-asm.h:947: Warning: ignoring redefinition of = register alias 'dst_w' > ./pixman-arm-neon-asm.h:947: Warning: ignoring redefinition of = register alias 'src' > ./pixman-arm-neon-asm.h:947: Warning: ignoring redefinition of = register alias 'dst_r' > ./pixman-arm-neon-asm.h:947: Warning: ignoring redefinition of = register alias 'mask' > ./pixman-arm-neon-asm.h:947: Warning: ignoring redefinition of = register alias 'dst_w' > ./pixman-arm-neon-asm.h:947: Warning: ignoring redefinition of = register alias 'src' > ./pixman-arm-neon-asm.h:947: Warning: ignoring redefinition of = register alias 'dst_r' > ./pixman-arm-neon-asm.h:947: Warning: ignoring redefinition of = register alias 'mask' > ./pixman-arm-neon-asm.h:947: Warning: ignoring redefinition of = register alias 'dst_w' > ./pixman-arm-neon-asm.h:947: Warning: ignoring redefinition of = register alias 'src' > ./pixman-arm-neon-asm.h:947: Warning: ignoring redefinition of = register alias 'dst_r' > ./pixman-arm-neon-asm.h:947: Warning: ignoring redefinition of = register alias 'mask' > ./pixman-arm-neon-asm.h:708: Warning: ignoring redefinition of = register alias 'orig_w' > ./pixman-arm-neon-asm.h:708: Warning: ignoring redefinition of = register alias 'dummy' > ./pixman-arm-neon-asm.h:708: Warning: ignoring redefinition of = register alias 'orig_w' > ./pixman-arm-neon-asm.h:708: Warning: ignoring redefinition of = register alias 'dummy' > ./pixman-arm-neon-asm.h:708: Warning: ignoring redefinition of = register alias 'orig_w' > ./pixman-arm-neon-asm.h:708: Warning: ignoring redefinition of = register alias 'dummy' > ./pixman-arm-neon-asm.h:708: Warning: ignoring redefinition of = register alias 'orig_w' > ./pixman-arm-neon-asm.h:708: Warning: ignoring redefinition of = register alias 'dummy' > ./pixman-arm-neon-asm.h:708: Warning: ignoring redefinition of = register alias 'orig_w' > ./pixman-arm-neon-asm.h:708: Warning: ignoring redefinition of = register alias 'dummy' > ./pixman-arm-neon-asm.h:708: Warning: ignoring redefinition of = register alias 'orig_w' > ./pixman-arm-neon-asm.h:708: Warning: ignoring redefinition of = register alias 'dummy' > ./pixman-arm-neon-asm.h:708: Warning: ignoring redefinition of = register alias 'orig_w' > ./pixman-arm-neon-asm.h:708: Warning: ignoring redefinition of = register alias 'dummy' > ./pixman-arm-neon-asm.h:708: Warning: ignoring redefinition of = register alias 'orig_w' > ./pixman-arm-neon-asm.h:708: Warning: ignoring redefinition of = register alias 'dummy' > ./pixman-arm-neon-asm.h:708: Warning: ignoring redefinition of = register alias 'orig_w' > ./pixman-arm-neon-asm.h:708: Warning: ignoring redefinition of = register alias 'dummy' > ./pixman-arm-neon-asm.h:708: Warning: ignoring redefinition of = register alias 'orig_w' > ./pixman-arm-neon-asm.h:708: Warning: ignoring redefinition of = register alias 'dummy' > ./pixman-arm-neon-asm.h:708: Warning: ignoring redefinition of = register alias 'orig_w' > ./pixman-arm-neon-asm.h:708: Warning: ignoring redefinition of = register alias 'dummy' > ./pixman-arm-neon-asm.h:708: Warning: ignoring redefinition of = register alias 'orig_w' > ./pixman-arm-neon-asm.h:708: Warning: ignoring redefinition of = register alias 'dummy' > ./pixman-arm-neon-asm.h:708: Warning: ignoring redefinition of = register alias 'orig_w' > ./pixman-arm-neon-asm.h:708: Warning: ignoring redefinition of = register alias 'dummy' > ./pixman-arm-neon-asm.h:708: Warning: ignoring redefinition of = register alias 'orig_w' > ./pixman-arm-neon-asm.h:708: Warning: ignoring redefinition of = register alias 'dummy' > ./pixman-arm-neon-asm.h:947: Warning: ignoring redefinition of = register alias 'dst_w' > ./pixman-arm-neon-asm.h:947: Warning: ignoring redefinition of = register alias 'src' > ./pixman-arm-neon-asm.h:947: Warning: ignoring redefinition of = register alias 'dst_r' > ./pixman-arm-neon-asm.h:947: Warning: ignoring redefinition of = register alias 'mask' > ./pixman-arm-neon-asm.h:708: Warning: ignoring redefinition of = register alias 'orig_w' > ./pixman-arm-neon-asm.h:708: Warning: ignoring redefinition of = register alias 'dummy' > ./pixman-arm-neon-asm.h:708: Warning: ignoring redefinition of = register alias 'orig_w' > ./pixman-arm-neon-asm.h:708: Warning: ignoring redefinition of = register alias 'dummy' > ./pixman-arm-neon-asm.h:947: Warning: ignoring redefinition of = register alias 'dst_w' > ./pixman-arm-neon-asm.h:947: Warning: ignoring redefinition of = register alias 'src' > ./pixman-arm-neon-asm.h:947: Warning: ignoring redefinition of = register alias 'dst_r' > ./pixman-arm-neon-asm.h:947: Warning: ignoring redefinition of = register alias 'mask' > ./pixman-arm-neon-asm.h:708: Warning: ignoring redefinition of = register alias 'orig_w' > ./pixman-arm-neon-asm.h:708: Warning: ignoring redefinition of = register alias 'dummy' > ./pixman-arm-neon-asm.h:947: Warning: ignoring redefinition of = register alias 'dst_w' > ./pixman-arm-neon-asm.h:947: Warning: ignoring redefinition of = register alias 'src' > ./pixman-arm-neon-asm.h:947: Warning: ignoring redefinition of = register alias 'dst_r' > ./pixman-arm-neon-asm.h:947: Warning: ignoring redefinition of = register alias 'mask' > ./pixman-arm-neon-asm.h:708: Warning: ignoring redefinition of = register alias 'orig_w' > ./pixman-arm-neon-asm.h:708: Warning: ignoring redefinition of = register alias 'dummy' > ./pixman-arm-neon-asm.h:708: Warning: ignoring redefinition of = register alias 'orig_w' > ./pixman-arm-neon-asm.h:708: Warning: ignoring redefinition of = register alias 'dummy' > ./pixman-arm-neon-asm.h:708: Warning: ignoring redefinition of = register alias 'orig_w' > ./pixman-arm-neon-asm.h:708: Warning: ignoring redefinition of = register alias 'dummy' > ./pixman-arm-neon-asm.h:708: Warning: ignoring redefinition of = register alias 'orig_w' > ./pixman-arm-neon-asm.h:708: Warning: ignoring redefinition of = register alias 'dummy' > ./pixman-arm-neon-asm.h:708: Warning: ignoring redefinition of = register alias 'orig_w' > ./pixman-arm-neon-asm.h:708: Warning: ignoring redefinition of = register alias 'dummy' > ./pixman-arm-neon-asm.h:708: Warning: ignoring redefinition of = register alias 'orig_w' > ./pixman-arm-neon-asm.h:708: Warning: ignoring redefinition of = register alias 'dummy' > ./pixman-arm-neon-asm.h:947: Warning: ignoring redefinition of = register alias 'dst_w' > ./pixman-arm-neon-asm.h:947: Warning: ignoring redefinition of = register alias 'src' > ./pixman-arm-neon-asm.h:947: Warning: ignoring redefinition of = register alias 'mask' > ./pixman-arm-neon-asm.h:947: Warning: ignoring redefinition of = register alias 'dst_w' > ./pixman-arm-neon-asm.h:947: Warning: ignoring redefinition of = register alias 'src' > ./pixman-arm-neon-asm.h:947: Warning: ignoring redefinition of = register alias 'mask' > ./pixman-arm-neon-asm.h:947: Warning: ignoring redefinition of = register alias 'dst_w' > ./pixman-arm-neon-asm.h:947: Warning: ignoring redefinition of = register alias 'src' > ./pixman-arm-neon-asm.h:947: Warning: ignoring redefinition of = register alias 'mask' > ./pixman-arm-neon-asm.h:947: Warning: ignoring redefinition of = register alias 'dst_w' > ./pixman-arm-neon-asm.h:947: Warning: ignoring redefinition of = register alias 'src' > ./pixman-arm-neon-asm.h:947: Warning: ignoring redefinition of = register alias 'mask' > ./pixman-arm-neon-asm.h:947: Warning: ignoring redefinition of = register alias 'dst_w' > ./pixman-arm-neon-asm.h:947: Warning: ignoring redefinition of = register alias 'src' > ./pixman-arm-neon-asm.h:947: Warning: ignoring redefinition of = register alias 'mask' > ./pixman-arm-neon-asm.h:947: Warning: ignoring redefinition of = register alias 'dst_w' > ./pixman-arm-neon-asm.h:947: Warning: ignoring redefinition of = register alias 'src' > ./pixman-arm-neon-asm.h:947: Warning: ignoring redefinition of = register alias 'mask' > pixman-arm-neon-asm.S:3623: Warning: ignoring redefinition of register = alias 'tmp1' > pixman-arm-neon-asm.S:3623: Warning: ignoring redefinition of register = alias 'tmp2' > pixman-arm-neon-asm.S:3627: Warning: ignoring redefinition of register = alias 'tmp1' > pixman-arm-neon-asm.S:3627: Warning: ignoring redefinition of register = alias 'tmp2' > pixman-arm-neon-asm.S:3631: Warning: ignoring redefinition of register = alias 'tmp1' > pixman-arm-neon-asm.S:3631: Warning: ignoring redefinition of register = alias 'tmp2' > pixman-arm-neon-asm.S:3635: Warning: ignoring redefinition of register = alias 'tmp1' > pixman-arm-neon-asm.S:3635: Warning: ignoring redefinition of register = alias 'tmp2' > cc: error: assembler command failed with exit code 1 (use -v to see = invocation) >=20 > Any suggestions? -- George > _______________________________________________ > 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 Tue Sep 17 02:19:28 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 2B40840B for ; Tue, 17 Sep 2013 02:19:28 +0000 (UTC) (envelope-from george+freebsd@m5p.com) Received: from mailhost.m5p.com (ip-2-1-0-2.r03.asbnva02.us.ce.gin.ntt.net [IPv6:2001:418:0:5000::16]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id D6FEC21E3 for ; Tue, 17 Sep 2013 02:19:27 +0000 (UTC) Received: from wonderland.m5p.com (localhost [IPv6:::1]) by mailhost.m5p.com (8.14.5/8.14.5) with ESMTP id r8H2JKc6024588; Mon, 16 Sep 2013 22:19:25 -0400 (EDT) (envelope-from george+freebsd@m5p.com) Message-ID: <5237BC28.8030709@m5p.com> Date: Mon, 16 Sep 2013 22:19:20 -0400 From: George Mitchell User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130716 Thunderbird/17.0.7 MIME-Version: 1.0 To: Chie Taguchi Subject: Re: What's the recipe? References: <522229C0.5030504@m5p.com> <5235D207.5070400@m5p.com> <6AE316FC-8B08-4F5D-B918-7F97C8C4CB60@gmail.com> In-Reply-To: <6AE316FC-8B08-4F5D-B918-7F97C8C4CB60@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.73 on 10.100.0.3 X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.7 (mailhost.m5p.com [IPv6:::1]); Mon, 16 Sep 2013 22:19:26 -0400 (EDT) Cc: "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Sep 2013 02:19:28 -0000 On 09/16/13 22:00, Chie Taguchi wrote: > Have you tried ports/181140? > > C.Taguchi Yes; google pointed me there a little earlier today. But the syntax of the patch appears to be slightly off. Here's what works for me: ... .if ! {PORT_OPTIONS:MSIMD} CONFIGURE_ARGS+= --disable-vmx --disable-arm-simd .if ! {MACHINE_CPU:Mmmx} CONFIGURE_ARGS+= --disable-mmx .endif .if ! {MACHINE_CPU:Msse2} CONFIGURE_ARGS+= --disable-sse2 .endif .endif .if ${ARCH} == arm || ${ARCH} == armv6 CONFIGURE_ARGS+= --disable-arm-neon .endif ... (The patch had "${MACHINE_CPU:Mmmx}" and "${MACHINE_CPU:Msse2}", but make didn't like the dollar signs.) My next problem is that my devel/glib20 build somehow didn't populate /usr/local/include/glib-2.0/gio, so devel/gobject-introspection couldn't build. I'm rerunning the devel/glib20 build to see if it works better the second time. -- George > > On 2013/09/16, at 0:28, George Mitchell wrote: > >> On 08/31/13 13:37, George Mitchell wrote: >>> Have you built a working Raspberry Pi image recently? If so, for the >>> benefit of the rest of us, could you share a few secrets? >>> >>> 1. What system did you do the build on? If it was an i386 or amd64, >>> what svn version was it built with? >> >> Built on amd64, svn version r255361M. (Two changes: I still distrust >> SCHED_ULE, and there's a patch [attached] required for the ARM xdev >> build to complete.) >>> >>> 2. What did you have in /etc/src.conf and /etc/make.conf, both for >>> building the build system itself and for building the RPi? >> >> I finally bit the bullet and went to clang. /etc/src.conf is empty; >> /etc/make.conf contains "WITH_PKGNG=yes". >>> >>> 3. What svn version of /usr/src did you use in building the RPi image? >>> >> Same as above (r255361M). >> >>> 4. Did you use crochet? If so, what was the last commit in your git >>> log? >> commit b154a2f1252eaa5f4d821439d0d9005cea94e580 >> Merge: a6f4cc5 8d03c23 >> Author: Tim Kientzle >> Date: Sat Aug 17 12:00:52 2013 -0700 >> >>> >>> When I say "working," I'm hoping for the ability to run stably for a >>> number of days, running NFS and CUPS. I've been doing this since >>> January with a precompiled image I downloaded then which worked >>> wonderfully with one of my printers, but not the other one. Now >>> there's a patch that enables both printers to work, and I would love >>> to build a new image. So I've been thrashing around trying to find >>> the answers to the questions above without success. Thanks for any >>> help you can give! -- George >> >> This build is marginally stable. I've been working for a week to get >> a complete build of print/cups and I'm not quite there. From the RPi, >> /usr/ports is an NFS mount from another machine with version 326306 of >> the ports tree (just before the iconv incident). The RPi likes to get >> messages of this sort: >> >> http://www.m5p.com/~george/pi/DSCN1282.JPG >> >> primarily during the period that portmaster is discovering everybody's >> dependencies. (Oddly, if I make it to the build stage, the build >> completes about 90% of the time. devel/glib20 built, including its >> dependencies on perl and python, in one overnight session.) >> >> Once, instead of the fatal kernel mode prefetch abort, I got: >> >> panic: __rw_wlock_hard: recursing but non-recursive rw pmap pw @ /usr/src/sys/arm/arm/pmap-v6.c:1406 >> KDB: enter: panic [ thread pid 906 tid 100076 ] >> stopped at $d: ldrb r15, [r15, 15, ror r15] >> >> (Sorry for the transcription by hand; I have an AdaFruit serial cable >> on order.) >> >> My current problem is that x11/pixman fails to build: >> >> ===> Building for pixman-0.30.0 >> [...] >> CC pixman-arm-neon.lo >> CPPAS pixman-arm-neon-asm.lo >> /usr/include/float.h: Assembler messages: >> /usr/include/float.h:43: Error: bad instruction `extern int __flt_rounds(void)' >> [...] From owner-freebsd-arm@FreeBSD.ORG Tue Sep 17 04:07:32 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 6B718447 for ; Tue, 17 Sep 2013 04:07:32 +0000 (UTC) (envelope-from taguchi.ch@gmail.com) Received: from mail-pa0-x22b.google.com (mail-pa0-x22b.google.com [IPv6:2607:f8b0:400e:c03::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 4188327D6 for ; Tue, 17 Sep 2013 04:07:32 +0000 (UTC) Received: by mail-pa0-f43.google.com with SMTP id hz10so6236157pad.16 for ; Mon, 16 Sep 2013 21:07:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=GP9JzCJj4OH0aFcuUZntsPuvAK/tei2CbWjRp9gXvUI=; b=Ro2h/LJHBRgo4cIFX+8qyBdqGmtIsm/BiQn7qkSA0u4QJmtOKfMmvMerK3oSDLhrG/ PcPLocqN+Dqldg3s9uZGCzUT+ZZEdmb8T5K6wiVOtlllDk8koeWMGOeDIG4MDV/LiKRW 61jUziXgGFf2FDkAMJaUUphv1YjqBcbHdpUAqShJkhOCR7ostLV1w5i4uEHAjrDsPXAt xHHT9vvTuMB2vl2ALIS9/olG1IL+AxWleffe73kn8vethdKirNCd5z1Hk6lweUzqdUsC dE54PTlbVNkWyP+68xVvXW2q4Z3A+gjIaMSncbFhKNafTtueyRGNM/9gzqfCv65aYVaT W4Yw== X-Received: by 10.68.191.193 with SMTP id ha1mr5499457pbc.166.1379390851938; Mon, 16 Sep 2013 21:07:31 -0700 (PDT) Received: from [10.0.1.203] (48.178.30.125.dy.iij4u.or.jp. [125.30.178.48]) by mx.google.com with ESMTPSA id wd6sm42701686pab.3.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 16 Sep 2013 21:07:31 -0700 (PDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Subject: Re: What's the recipe? From: Chie Taguchi In-Reply-To: <5237BC28.8030709@m5p.com> Date: Tue, 17 Sep 2013 13:07:28 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: <8B750CD2-53BB-478A-8C7E-369226AA9997@gmail.com> References: <522229C0.5030504@m5p.com> <5235D207.5070400@m5p.com> <6AE316FC-8B08-4F5D-B918-7F97C8C4CB60@gmail.com> <5237BC28.8030709@m5p.com> To: George Mitchell X-Mailer: Apple Mail (2.1508) Cc: "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Sep 2013 04:07:32 -0000 It will cause following issue in building devel/glib20: /bin/mkdir -p '/usr/local/include/glib-2.0/gio/' : jemalloc_arena.c:380: Failed assertion: "p[i] =3D=3D 0" Abort trap (core dumped) This is a very annoy problem, and glib20 ignore this error. As a result, glib20 fail to install some header files. This workaround is rebuild your image with "MALLOC_PRODUCTION=3Dyes". Thanks. C.Taguchi On 2013/09/17, at 11:19, George Mitchell wrote: > On 09/16/13 22:00, Chie Taguchi wrote: >> Have you tried ports/181140? >>=20 >> C.Taguchi >=20 > Yes; google pointed me there a little earlier today. But the syntax > of the patch appears to be slightly off. Here's what works for me: >=20 > ... > .if ! {PORT_OPTIONS:MSIMD} > CONFIGURE_ARGS+=3D --disable-vmx --disable-arm-simd > .if ! {MACHINE_CPU:Mmmx} > CONFIGURE_ARGS+=3D --disable-mmx > .endif > .if ! {MACHINE_CPU:Msse2} > CONFIGURE_ARGS+=3D --disable-sse2 > .endif > .endif >=20 > .if ${ARCH} =3D=3D arm || ${ARCH} =3D=3D armv6 > CONFIGURE_ARGS+=3D --disable-arm-neon > .endif > ... >=20 > (The patch had "${MACHINE_CPU:Mmmx}" and "${MACHINE_CPU:Msse2}", but > make didn't like the dollar signs.) >=20 > My next problem is that my devel/glib20 build somehow didn't populate > /usr/local/include/glib-2.0/gio, so devel/gobject-introspection = couldn't > build. I'm rerunning the devel/glib20 build to see if it works better > the second time. -- George >=20 >>=20 >> On 2013/09/16, at 0:28, George Mitchell = wrote: >>=20 >>> On 08/31/13 13:37, George Mitchell wrote: >>>> Have you built a working Raspberry Pi image recently? If so, for = the >>>> benefit of the rest of us, could you share a few secrets? >>>>=20 >>>> 1. What system did you do the build on? If it was an i386 or = amd64, >>>> what svn version was it built with? >>>=20 >>> Built on amd64, svn version r255361M. (Two changes: I still = distrust >>> SCHED_ULE, and there's a patch [attached] required for the ARM xdev >>> build to complete.) >>>>=20 >>>> 2. What did you have in /etc/src.conf and /etc/make.conf, both for >>>> building the build system itself and for building the RPi? >>>=20 >>> I finally bit the bullet and went to clang. /etc/src.conf is empty; >>> /etc/make.conf contains "WITH_PKGNG=3Dyes". >>>>=20 >>>> 3. What svn version of /usr/src did you use in building the RPi = image? >>>>=20 >>> Same as above (r255361M). >>>=20 >>>> 4. Did you use crochet? If so, what was the last commit in your = git >>>> log? >>> commit b154a2f1252eaa5f4d821439d0d9005cea94e580 >>> Merge: a6f4cc5 8d03c23 >>> Author: Tim Kientzle >>> Date: Sat Aug 17 12:00:52 2013 -0700 >>>=20 >>>>=20 >>>> When I say "working," I'm hoping for the ability to run stably for = a >>>> number of days, running NFS and CUPS. I've been doing this since >>>> January with a precompiled image I downloaded then which worked >>>> wonderfully with one of my printers, but not the other one. Now >>>> there's a patch that enables both printers to work, and I would = love >>>> to build a new image. So I've been thrashing around trying to find >>>> the answers to the questions above without success. Thanks for any >>>> help you can give! -- = George >>>=20 >>> This build is marginally stable. I've been working for a week to = get >>> a complete build of print/cups and I'm not quite there. =46rom the = RPi, >>> /usr/ports is an NFS mount from another machine with version 326306 = of >>> the ports tree (just before the iconv incident). The RPi likes to = get >>> messages of this sort: >>>=20 >>> http://www.m5p.com/~george/pi/DSCN1282.JPG >>>=20 >>> primarily during the period that portmaster is discovering = everybody's >>> dependencies. (Oddly, if I make it to the build stage, the build >>> completes about 90% of the time. devel/glib20 built, including its >>> dependencies on perl and python, in one overnight session.) >>>=20 >>> Once, instead of the fatal kernel mode prefetch abort, I got: >>>=20 >>> panic: __rw_wlock_hard: recursing but non-recursive rw pmap pw @ = /usr/src/sys/arm/arm/pmap-v6.c:1406 >>> KDB: enter: panic [ thread pid 906 tid 100076 ] >>> stopped at $d: ldrb r15, [r15, 15, ror r15] >>>=20 >>> (Sorry for the transcription by hand; I have an AdaFruit serial = cable >>> on order.) >>>=20 >>> My current problem is that x11/pixman fails to build: >>>=20 >>> =3D=3D=3D> Building for pixman-0.30.0 >>> [...] >>> CC pixman-arm-neon.lo >>> CPPAS pixman-arm-neon-asm.lo >>> /usr/include/float.h: Assembler messages: >>> /usr/include/float.h:43: Error: bad instruction `extern int = __flt_rounds(void)' >>> [...] From owner-freebsd-arm@FreeBSD.ORG Tue Sep 17 11:00:04 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 19CB8925 for ; Tue, 17 Sep 2013 11:00:04 +0000 (UTC) (envelope-from george+freebsd@m5p.com) Received: from mailhost.m5p.com (ip-2-1-0-2.r03.asbnva02.us.ce.gin.ntt.net [IPv6:2001:418:0:5000::16]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 9497C2D5F for ; Tue, 17 Sep 2013 11:00:03 +0000 (UTC) Received: from wonderland.m5p.com (localhost [IPv6:::1]) by mailhost.m5p.com (8.14.5/8.14.5) with ESMTP id r8HAwJF6028720; Tue, 17 Sep 2013 07:00:00 -0400 (EDT) (envelope-from george+freebsd@m5p.com) Message-ID: <523835CB.2070900@m5p.com> Date: Tue, 17 Sep 2013 06:58:19 -0400 From: George Mitchell User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130716 Thunderbird/17.0.7 MIME-Version: 1.0 To: Chie Taguchi Subject: Re: What's the recipe? References: <522229C0.5030504@m5p.com> <5235D207.5070400@m5p.com> <6AE316FC-8B08-4F5D-B918-7F97C8C4CB60@gmail.com> <5237BC28.8030709@m5p.com> <8B750CD2-53BB-478A-8C7E-369226AA9997@gmail.com> In-Reply-To: <8B750CD2-53BB-478A-8C7E-369226AA9997@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.73 on 10.100.0.3 X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.7 (mailhost.m5p.com [IPv6:::1]); Tue, 17 Sep 2013 07:00:01 -0400 (EDT) Cc: "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Sep 2013 11:00:04 -0000 On 09/17/13 00:07, Chie Taguchi wrote: > It will cause following issue in building devel/glib20: > > /bin/mkdir -p '/usr/local/include/glib-2.0/gio/' > : jemalloc_arena.c:380: Failed assertion: "p[i] == 0" > Abort trap (core dumped) > > This is a very annoy problem, and glib20 ignore this error. > As a result, glib20 fail to install some header files. > > This workaround is rebuild your image with "MALLOC_PRODUCTION=yes". > > Thanks. > > C.Taguchi Thanks! I'll try that tonight. -- George > > > On 2013/09/17, at 11:19, George Mitchell wrote: > >> On 09/16/13 22:00, Chie Taguchi wrote: >>> Have you tried ports/181140? >>> >>> C.Taguchi >> >> Yes; google pointed me there a little earlier today. But the syntax >> of the patch appears to be slightly off. Here's what works for me: >> >> ... >> .if ! {PORT_OPTIONS:MSIMD} >> CONFIGURE_ARGS+= --disable-vmx --disable-arm-simd >> .if ! {MACHINE_CPU:Mmmx} >> CONFIGURE_ARGS+= --disable-mmx >> .endif >> .if ! {MACHINE_CPU:Msse2} >> CONFIGURE_ARGS+= --disable-sse2 >> .endif >> .endif >> >> .if ${ARCH} == arm || ${ARCH} == armv6 >> CONFIGURE_ARGS+= --disable-arm-neon >> .endif >> ... >> >> (The patch had "${MACHINE_CPU:Mmmx}" and "${MACHINE_CPU:Msse2}", but >> make didn't like the dollar signs.) >> >> My next problem is that my devel/glib20 build somehow didn't populate >> /usr/local/include/glib-2.0/gio, so devel/gobject-introspection couldn't >> build. I'm rerunning the devel/glib20 build to see if it works better >> the second time. -- George >> >>> >>> On 2013/09/16, at 0:28, George Mitchell wrote: >>> >>>> On 08/31/13 13:37, George Mitchell wrote: >>>>> Have you built a working Raspberry Pi image recently? If so, for the >>>>> benefit of the rest of us, could you share a few secrets? >>>>> >>>>> 1. What system did you do the build on? If it was an i386 or amd64, >>>>> what svn version was it built with? >>>> >>>> Built on amd64, svn version r255361M. (Two changes: I still distrust >>>> SCHED_ULE, and there's a patch [attached] required for the ARM xdev >>>> build to complete.) >>>>> >>>>> 2. What did you have in /etc/src.conf and /etc/make.conf, both for >>>>> building the build system itself and for building the RPi? >>>> >>>> I finally bit the bullet and went to clang. /etc/src.conf is empty; >>>> /etc/make.conf contains "WITH_PKGNG=yes". >>>>> >>>>> 3. What svn version of /usr/src did you use in building the RPi image? >>>>> >>>> Same as above (r255361M). >>>> >>>>> 4. Did you use crochet? If so, what was the last commit in your git >>>>> log? >>>> commit b154a2f1252eaa5f4d821439d0d9005cea94e580 >>>> Merge: a6f4cc5 8d03c23 >>>> Author: Tim Kientzle >>>> Date: Sat Aug 17 12:00:52 2013 -0700 >>>> >>>>> >>>>> When I say "working," I'm hoping for the ability to run stably for a >>>>> number of days, running NFS and CUPS. I've been doing this since >>>>> January with a precompiled image I downloaded then which worked >>>>> wonderfully with one of my printers, but not the other one. Now >>>>> there's a patch that enables both printers to work, and I would love >>>>> to build a new image. So I've been thrashing around trying to find >>>>> the answers to the questions above without success. Thanks for any >>>>> help you can give! -- George >>>> >>>> This build is marginally stable. I've been working for a week to get >>>> a complete build of print/cups and I'm not quite there. From the RPi, >>>> /usr/ports is an NFS mount from another machine with version 326306 of >>>> the ports tree (just before the iconv incident). The RPi likes to get >>>> messages of this sort: >>>> >>>> http://www.m5p.com/~george/pi/DSCN1282.JPG >>>> >>>> primarily during the period that portmaster is discovering everybody's >>>> dependencies. (Oddly, if I make it to the build stage, the build >>>> completes about 90% of the time. devel/glib20 built, including its >>>> dependencies on perl and python, in one overnight session.) >>>> >>>> Once, instead of the fatal kernel mode prefetch abort, I got: >>>> >>>> panic: __rw_wlock_hard: recursing but non-recursive rw pmap pw @ /usr/src/sys/arm/arm/pmap-v6.c:1406 >>>> KDB: enter: panic [ thread pid 906 tid 100076 ] >>>> stopped at $d: ldrb r15, [r15, 15, ror r15] >>>> >>>> (Sorry for the transcription by hand; I have an AdaFruit serial cable >>>> on order.) >>>> >>>> My current problem is that x11/pixman fails to build: >>>> >>>> ===> Building for pixman-0.30.0 >>>> [...] >>>> CC pixman-arm-neon.lo >>>> CPPAS pixman-arm-neon-asm.lo >>>> /usr/include/float.h: Assembler messages: >>>> /usr/include/float.h:43: Error: bad instruction `extern int __flt_rounds(void)' >>>> [...] > From owner-freebsd-arm@FreeBSD.ORG Tue Sep 17 14:13:42 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 09E77AA6 for ; Tue, 17 Sep 2013 14:13:42 +0000 (UTC) (envelope-from ronald-freebsd8@klop.yi.org) Received: from cpsmtpb-ews04.kpnxchange.com (cpsmtpb-ews04.kpnxchange.com [213.75.39.7]) by mx1.freebsd.org (Postfix) with ESMTP id 94E0B281E for ; Tue, 17 Sep 2013 14:13:41 +0000 (UTC) Received: from cpsps-ews24.kpnxchange.com ([10.94.84.190]) by cpsmtpb-ews04.kpnxchange.com with Microsoft SMTPSVC(7.5.7601.17514); Tue, 17 Sep 2013 16:13:32 +0200 Received: from CPSMTPM-TLF104.kpnxchange.com ([195.121.3.7]) by cpsps-ews24.kpnxchange.com with Microsoft SMTPSVC(7.5.7601.17514); Tue, 17 Sep 2013 16:13:31 +0200 Received: from sjakie.klop.ws ([212.182.167.131]) by CPSMTPM-TLF104.kpnxchange.com with Microsoft SMTPSVC(7.5.7601.17514); Tue, 17 Sep 2013 16:13:32 +0200 Received: from 212-182-167-131.ip.telfort.nl (localhost [127.0.0.1]) by sjakie.klop.ws (Postfix) with ESMTP id 6C83717C23 for ; Tue, 17 Sep 2013 16:13:29 +0200 (CEST) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Subject: svn on armv5 with clang? (Fwd: svn commit: r254539 - head/usr.bin) References: <201308191744.r7JHiJ00063824@svn.freebsd.org> To: "freebsd-arm@freebsd.org" Date: Tue, 17 Sep 2013 16:13:22 +0200 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Ronald Klop" Message-ID: In-Reply-To: <201308191744.r7JHiJ00063824@svn.freebsd.org> User-Agent: Opera Mail/12.16 (FreeBSD) X-OriginalArrivalTime: 17 Sep 2013 14:13:32.0168 (UTC) FILETIME=[16FDF080:01CEB3B0] X-RcptDomain: freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Sep 2013 14:13:42 -0000 Hi, I am reading up on commits and found this one. Is ARMv5 capable of building the in-tree svn also? Ronald. ------- Forwarded message ------- From: "Andrew Turner" To: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Cc: Subject: svn commit: r254539 - head/usr.bin Date: Mon, 19 Aug 2013 19:44:19 +0200 Author: andrew Date: Mon Aug 19 17:44:19 2013 New Revision: 254539 URL: http://svnweb.freebsd.org/changeset/base/254539 Log: Subversion requires atomic functions we only support on arm with clang. Modified: head/usr.bin/Makefile Modified: head/usr.bin/Makefile ============================================================================== --- head/usr.bin/Makefile Mon Aug 19 17:09:14 2013 (r254538) +++ head/usr.bin/Makefile Mon Aug 19 17:44:19 2013 (r254539) @@ -366,7 +366,9 @@ SUBDIR+= users SUBDIR+= who .endif -.if ${MACHINE_ARCH} == "amd64" || ${MACHINE_ARCH} == "ia64" || ${MACHINE_ARCH} == "sparc64" || ${MACHINE_ARCH} == "i386" || ${MACHINE_ARCH} == "armv6" +.if ${MACHINE_ARCH} == "amd64" || ${MACHINE_ARCH} == "ia64" || \ + ${MACHINE_ARCH} == "sparc64" || ${MACHINE_ARCH} == "i386" || \ + (${MACHINE_ARCH} == "armv6" && ${COMPILER_TYPE} == "clang") .if ${MK_SVN} == "yes" || ${MK_SVNLITE} == "yes" SUBDIR+= svn .endif _______________________________________________ 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 Tue Sep 17 18:02:29 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 2C0BF24B for ; Tue, 17 Sep 2013 18:02:29 +0000 (UTC) (envelope-from andrew@fubar.geek.nz) Received: from nibbler.fubar.geek.nz (nibbler.fubar.geek.nz [199.48.134.198]) by mx1.freebsd.org (Postfix) with ESMTP id 0E63C2780 for ; Tue, 17 Sep 2013 18:02:28 +0000 (UTC) Received: from bender.Home (97e5e46b.skybroadband.com [151.229.228.107]) by nibbler.fubar.geek.nz (Postfix) with ESMTPSA id BE8975DFFE; Tue, 17 Sep 2013 18:02:21 +0000 (UTC) Date: Tue, 17 Sep 2013 19:02:15 +0100 From: Andrew Turner To: "Ronald Klop" Subject: Re: svn on armv5 with clang? (Fwd: svn commit: r254539 - head/usr.bin) Message-ID: <20130917190215.7093f261@bender.Home> In-Reply-To: References: <201308191744.r7JHiJ00063824@svn.freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Sep 2013 18:02:29 -0000 On Tue, 17 Sep 2013 16:13:22 +0200 "Ronald Klop" wrote: > Hi, > > I am reading up on commits and found this one. Is ARMv5 capable of > building the in-tree svn also? > It is unlikely, I don't think we provide the required atomic functions for ARMv5. On armv6 clang provides them, however I don't thing it knows how to set up ARM_RAS_START. Without this we have to implement more of the __sync_* functions for svn to work on ARMv5. I don't know of any plans to add them. Andrew From owner-freebsd-arm@FreeBSD.ORG Tue Sep 17 18:48:12 2013 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id E527F176 for ; Tue, 17 Sep 2013 18:48:12 +0000 (UTC) (envelope-from ian@FreeBSD.org) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id B9A1629F1 for ; Tue, 17 Sep 2013 18:48:12 +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 1VLzxC-000Fe7-0Z; Tue, 17 Sep 2013 18:24:50 +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 r8HIOkV8014104; Tue, 17 Sep 2013 12:24:46 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+3OIW0Ie+Nh/nO3Pbu0xib Subject: Re: svn on armv5 with clang? (Fwd: svn commit: r254539 - head/usr.bin) From: Ian Lepore To: Andrew Turner In-Reply-To: <20130917190215.7093f261@bender.Home> References: <201308191744.r7JHiJ00063824@svn.freebsd.org> <20130917190215.7093f261@bender.Home> Content-Type: text/plain; charset="us-ascii" Date: Tue, 17 Sep 2013 12:24:45 -0600 Message-ID: <1379442285.1197.49.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" , Ronald Klop X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Sep 2013 18:48:13 -0000 On Tue, 2013-09-17 at 19:02 +0100, Andrew Turner wrote: > On Tue, 17 Sep 2013 16:13:22 +0200 > "Ronald Klop" wrote: > > > Hi, > > > > I am reading up on commits and found this one. Is ARMv5 capable of > > building the in-tree svn also? > > > It is unlikely, I don't think we provide the required atomic functions > for ARMv5. On armv6 clang provides them, however I don't thing it knows > how to set up ARM_RAS_START. Without this we have to implement more of > the __sync_* functions for svn to work on ARMv5. I don't know of any > plans to add them. > I don't remember ever hearing about plans to *drop* support for armv4 and v5, but with responses like that, that seems to be what's underway. -- Ian From owner-freebsd-arm@FreeBSD.ORG Tue Sep 17 19:45:46 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 6AC7F679 for ; Tue, 17 Sep 2013 19:45:46 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-vb0-f43.google.com (mail-vb0-f43.google.com [209.85.212.43]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 22E582E0F for ; Tue, 17 Sep 2013 19:45:45 +0000 (UTC) Received: by mail-vb0-f43.google.com with SMTP id h11so4364876vbh.2 for ; Tue, 17 Sep 2013 12:45:39 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=B9mgcGzEfdU2GZZ0p9xe4IzuXLULpSIQWHhmp8HMWzg=; b=J4OzNOLaWxcaz1kz8YNqEsNJHhcDlWnZa9hiRu+STmmy581Ii4t1j6ondzymzJyfXy DAWRTmtDMShj/pJ3/dpCUz9cHA1VhKyV8gyQpTcdK1Wc5MF4fNgIlEr87wnsejrDI5m2 SbEBmR0ZXWwATABXO/Ysj67HdvB0zWGAMNpYR7SF7TaQch69LEHSkK2uUzV/gmuoCFCh bR5aJMlZqAZKfrHi1DHG92+A/1dPzsfjmAOcgrlapmnptq1ZxJ/SLdCdHVieGQVQ1OSd YfOtbuTPaO0cEVIpjEMtPmQvfmiAtpmV43ckcyZVmanVFgM5TN5fZ8Kkrw41aPfQXqiz R4/w== X-Gm-Message-State: ALoCoQlF/ZZd4J3wOqrCcLCcR1nbT/34sRIKwNnmuxTlrZQSLgwSR7sT45QxmtMyMxCjZh9MxCjF X-Received: by 10.58.75.18 with SMTP id y18mr1743138vev.33.1379446723275; Tue, 17 Sep 2013 12:38:43 -0700 (PDT) Received: from fusionlt2834a.int.fusionio.com ([209.117.142.2]) by mx.google.com with ESMTPSA id eu2sm20338887vdc.2.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 17 Sep 2013 12:38:42 -0700 (PDT) Sender: Warner Losh Subject: Re: svn on armv5 with clang? (Fwd: svn commit: r254539 - head/usr.bin) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <1379442285.1197.49.camel@revolution.hippie.lan> Date: Tue, 17 Sep 2013 13:38:40 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201308191744.r7JHiJ00063824@svn.freebsd.org> <20130917190215.7093f261@bender.Home> <1379442285.1197.49.camel@revolution.hippie.lan> To: Ian Lepore X-Mailer: Apple Mail (2.1085) Cc: "freebsd-arm@freebsd.org" , Ronald Klop X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Sep 2013 19:45:46 -0000 On Sep 17, 2013, at 12:24 PM, Ian Lepore wrote: > On Tue, 2013-09-17 at 19:02 +0100, Andrew Turner wrote: >> On Tue, 17 Sep 2013 16:13:22 +0200 >> "Ronald Klop" wrote: >>=20 >>> Hi, >>>=20 >>> I am reading up on commits and found this one. Is ARMv5 capable of =20= >>> building the in-tree svn also? >>>=20 >> It is unlikely, I don't think we provide the required atomic = functions >> for ARMv5. On armv6 clang provides them, however I don't thing it = knows >> how to set up ARM_RAS_START. Without this we have to implement more = of >> the __sync_* functions for svn to work on ARMv5. I don't know of any >> plans to add them. >>=20 >=20 > I don't remember ever hearing about plans to *drop* support for armv4 > and v5, but with responses like that, that seems to be what's = underway. There were *NO* such plans, and if there are it is taking me by = surprise. ARM_RAS_START is critical to support armv4/5. I thought it was a = #define... no? Warner From owner-freebsd-arm@FreeBSD.ORG Tue Sep 17 21:50:00 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 6BE2AA08 for ; Tue, 17 Sep 2013 21:50:00 +0000 (UTC) (envelope-from werner@thie.ch) Received: from newton.metanet.ch (newton.metanet.ch [80.74.158.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id A72DB2606 for ; Tue, 17 Sep 2013 21:49:58 +0000 (UTC) Received: (qmail 12341 invoked from network); 17 Sep 2013 23:43:15 +0200 Received: from udp004035uds.hawaiiantel.net (HELO ?192.168.1.16?) (72.234.77.213) by newton.metanet.ch with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 17 Sep 2013 23:43:15 +0200 Message-ID: <5238CCF1.9070209@thie.ch> Date: Tue, 17 Sep 2013 11:43:13 -1000 From: Werner Thie Organization: privat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: freebsd-arm@freebsd.org Subject: Re: crochet failing when installing ubldr References: <52354E8F.1010808@makani-kai.com> <1379250419.1197.43.camel@revolution.hippie.lan> <9D6FACB2-015D-4CE8-98F0-01AA501F1367@kientzle.com> <52361103.80001@makani-kai.com> In-Reply-To: <52361103.80001@makani-kai.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: werner@thie.ch List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Sep 2013 21:50:00 -0000 Hi all just as a follow up, after quite some tinkering with git and stashing away my changes, going back and forth, I ended up with crochet doing it's work cleanly! I'm able to build images again with crochet :-) Mahalo Tim! Werner From owner-freebsd-arm@FreeBSD.ORG Tue Sep 17 21:59:27 2013 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 6968FD6F; Tue, 17 Sep 2013 21:59:27 +0000 (UTC) (envelope-from andrew@fubar.geek.nz) Received: from nibbler.fubar.geek.nz (nibbler.fubar.geek.nz [199.48.134.198]) by mx1.freebsd.org (Postfix) with ESMTP id 4ABAE2708; Tue, 17 Sep 2013 21:59:27 +0000 (UTC) Received: from bender.Home (97e5e46b.skybroadband.com [151.229.228.107]) by nibbler.fubar.geek.nz (Postfix) with ESMTPSA id CDA375E30D; Tue, 17 Sep 2013 21:59:25 +0000 (UTC) Date: Tue, 17 Sep 2013 22:59:18 +0100 From: Andrew Turner To: Ian Lepore Subject: Re: svn on armv5 with clang? (Fwd: svn commit: r254539 - head/usr.bin) Message-ID: <20130917225918.7a4728b1@bender.Home> In-Reply-To: <1379442285.1197.49.camel@revolution.hippie.lan> References: <201308191744.r7JHiJ00063824@svn.freebsd.org> <20130917190215.7093f261@bender.Home> <1379442285.1197.49.camel@revolution.hippie.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: "freebsd-arm@freebsd.org" , Ronald Klop X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Sep 2013 21:59:27 -0000 On Tue, 17 Sep 2013 12:24:45 -0600 Ian Lepore wrote: > On Tue, 2013-09-17 at 19:02 +0100, Andrew Turner wrote: > > On Tue, 17 Sep 2013 16:13:22 +0200 > > "Ronald Klop" wrote: > > > > > Hi, > > > > > > I am reading up on commits and found this one. Is ARMv5 capable > > > of building the in-tree svn also? > > > > > It is unlikely, I don't think we provide the required atomic > > functions for ARMv5. On armv6 clang provides them, however I don't > > thing it knows how to set up ARM_RAS_START. Without this we have to > > implement more of the __sync_* functions for svn to work on ARMv5. > > I don't know of any plans to add them. > > > > I don't remember ever hearing about plans to *drop* support for armv4 > and v5, but with responses like that, that seems to be what's > underway. That is because there are no plans to drop armv4/5 support, however I am also unaware of any plans to implement the required functions that clang provides on armv6. The only support I am planning on dropping is for armv6eb[1] as it is unused, and almost certainly broken. None of our kernels can boot on ARMv6/7, and the little-endian kernels don't have the required magic to be able to switch endian when required. Andrew [1] http://people.freebsd.org/~andrew/rm_armv6eb.diff From owner-freebsd-arm@FreeBSD.ORG Tue Sep 17 22:00:16 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 34931DBD for ; Tue, 17 Sep 2013 22:00:16 +0000 (UTC) (envelope-from fabiodive@gmail.com) Received: from mail-we0-x22b.google.com (mail-we0-x22b.google.com [IPv6:2a00:1450:400c:c03::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id C66B12739 for ; Tue, 17 Sep 2013 22:00:15 +0000 (UTC) Received: by mail-we0-f171.google.com with SMTP id t61so5587904wes.2 for ; Tue, 17 Sep 2013 15:00:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:date:message-id :cc:to:mime-version; bh=xIfQEu3c0WwB8hey0hM92EiKOUl6Vq+vPgzpkfCjI3A=; b=LBPnvWPzOL3Tuv+3i55W7zzHHrKK+vxr4PtQYS5nPgFJxFrpmhx++v5dC5UU0bdVQl NDcbJcbzGoYd0lJelhoIe7K3G3TP8eG/H+LG6NoRG6TG3S/r/nyrHQngW7jJPwNFxkYD kxplw37TCDjSUnglCfc1ZQr7fvxdgGWnAkhUJoED+MRfLjbsxhLNN+ERf1GHNS5wJEII mjgJfrSuVsa0FKKVTMNCnIwFiJ9/If+EUWQPX+EogWryrBwctigBGRAmG/CnwHdu6h/c 6F4HJ44csUxonDpYJt7mBIS3qx/A1L/iZvIdYfUbxii2OPMh7VHj4+G10SJx899hQXkK 2H+g== X-Received: by 10.180.107.167 with SMTP id hd7mr4268831wib.13.1379455214198; Tue, 17 Sep 2013 15:00:14 -0700 (PDT) Received: from [192.168.113.40] (135.Red-80-24-42.staticIP.rima-tde.net. [80.24.42.135]) by mx.google.com with ESMTPSA id dq11sm7401733wid.3.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 17 Sep 2013 15:00:13 -0700 (PDT) From: fabiodive Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: SPI device on Raspberry PI Date: Tue, 17 Sep 2013 23:00:11 +0100 Message-Id: <935B7003-F750-42E7-9100-C27028B6A111@gmail.com> To: Luiz Otavio O Souza Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) X-Mailer: Apple Mail (2.1510) Cc: "freebsd-arm@FreeBSD.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Sep 2013 22:00:16 -0000 Hello Luiz, I was able to use your patches on Raspberry PI, I builded an image with crochet and this is my dmesg output: root@:/usr/ports # dmesg KDB: debugger backends: ddb KDB: current backend: ddb Copyright (c) 1992-2013 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 10.0-ALPHA2 #0 r255620M: Tue Sep 17 02:45:12 UTC 2013 = seaman@bluehouse:/tank/projects/boreview_freebsd/crochet-freebsd/work/obj/= arm.armv6/tank/projects/boreview_freebsd/head/sys/RPI-B arm FreeBSD clang version 3.3 (tags/RELEASE_33/final 183502) 20130610 module_register: module iichb/iicbus already exists! Module iichb/iicbus failed to register: 17 CPU: ARM1176JZ-S rev 7 (ARM11J core) Supported features: ARM_ISA THUMB2 JAZELLE ARMv4 Security_Ext WB enabled LABT branch prediction enabled 16KB/32B 4-way instruction cache 16KB/32B 4-way write-back-locking-C data cache real memory =3D 536870912 (512 MB) avail memory =3D 484188160 (461 MB) kbd0 at kbdmux0 random: initialized simplebus0: mem 0x20000000-0x20ffffff = on fdtbus0 intc0: mem 0x2000b200-0x2000b3ff on = simplebus0 systimer0: mem 0x20003000-0x20003fff irq = 8,9,10,11 on simplebus0 Event timer "BCM2835 Event Timer 3" frequency 1000000 Hz quality 1000 Timecounter "BCM2835 Timecounter" frequency 1000000 Hz quality 1000 bcmwd0: mem 0x2010001c-0x20100027 on simplebus0 gpio0: mem 0x20200000-0x202000af irq = 57,59,58,60 on simplebus0 gpio0: read-only pins: 46,47,48,49,50,51,52,53. gpio0: reserved pins: 48,49,50,51,52,53. gpioc0: on gpio0 gpiobus0: on gpio0 iichb0: mem 0x20205000-0x2020501f irq 61 = on simplebus0 iicbus0: on iichb0 iic0: on iicbus0 iichb1: mem 0x20804000-0x2080401f irq 61 = on simplebus0 iicbus1: on iichb1 iic1: on iicbus1 spi0: mem 0x20204000-0x2020401f irq 62 on = simplebus0 spibus0: on spi0 miibus0: on smsc0 ukphy0: PHY 1 on miibus0 ukphy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto ue0: on smsc0 and this is /dev root@:/usr/ports # ls /dev bpf cuau0.lock iic0 log nfslock = stderr ttyv0 ttyv7 ttyve = uhid0 bpf0 devctl iic1 mdctl null = stdin ttyv1 ttyv8 ttyvf = ukbd0 console devstat kbd0 mem openfirm = stdout ttyv2 ttyv9 ufssuspend = urandom consolectl fd kbd1 mmcsd0 ptmx = sysmouse ttyv3 ttyva ugen0.1 = usb ctty fido kbdmux0 mmcsd0s1 pts = ttyu0 ttyv4 ttyvb ugen0.2 = usbctl cuau0 geom.ctl klog mmcsd0s2 random = ttyu0.init ttyv5 ttyvc ugen0.3 = xpt0 cuau0.init gpioc0 kmem mmcsd0s2a snp = ttyu0.lock ttyv6 ttyvd ugen0.4 = zero root@:/usr/ports #=20 Now.. I see the GPIO device and iic as well but what about SPI? Should I create the device or just use GPIO? Any ideas? Thank you Fabio= From owner-freebsd-arm@FreeBSD.ORG Wed Sep 18 08:18:20 2013 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id F2C73EB0 for ; Wed, 18 Sep 2013 08:18:19 +0000 (UTC) (envelope-from torfinn.ingolfsen@getmail.no) Received: from lamora.getmail.no (lamora.getmail.no [84.210.184.7]) by mx1.freebsd.org (Postfix) with ESMTP id 7B8222728 for ; Wed, 18 Sep 2013 08:18:19 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by lamora.getmail.no (Postfix) with ESMTP id C312E68192 for ; Wed, 18 Sep 2013 10:12:41 +0200 (CEST) X-Spam-Flag: NO X-Spam-Score: -2.95 X-Spam-Level: X-Spam-Status: No, score=-2.95 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_FB_WORD2_END_DOLLAR=0.01, T_TVD_SUBJ_NUM_OBFU=0.01, T_TVD_SUBJ_NUM_OBFU2=0.01, T_TVD_SUBJ_NUM_OBFU3=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 e7r7HBwGUS6D for ; Wed, 18 Sep 2013 10:12:41 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by lamora.getmail.no (Postfix) with ESMTP id 2CCB46CFAD for ; Wed, 18 Sep 2013 10:12:41 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.7.1 lamora.getmail.no 2CCB46CFAD DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=getmail.no; s=8A9C8B4C-D727-11E2-8095-B6466E6B3FA2; t=1379491961; bh=e1OT3SlF/cUqZxCSZu1hFtiERmBGWLUCjrQpfOHUT2c=; h=Date:From:To:Subject:Message-Id:Mime-Version:Content-Type: Content-Transfer-Encoding; b=Mt82kv4ihZvunWD4vAFLJEQvbaGCPtoyXFzo3j/YA3yDkjW4P07xDYqXVgwDDTw+l M3MX8Ls8Ska9jgYiG25ruqp5Km1DbaQ+FOVelRpUdNbCNuGnLgeBf9Q30Ik/n6u5Tn Sh9MU2vfDDCSA3sAGdbDF4MEcU9j04H1e8/+enUY= 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 WshTMf0QPtez for ; Wed, 18 Sep 2013 10:12:41 +0200 (CEST) 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 05A3F6BC5A for ; Wed, 18 Sep 2013 10:12:41 +0200 (CEST) Date: Wed, 18 Sep 2013 10:12:35 +0200 From: Torfinn Ingolfsen To: freebsd-arm@FreeBSD.org Subject: stm32flash under FreeBSD? Message-Id: <20130918101235.e1737d4bd839f71ebf554803@getmail.no> X-Mailer: Sylpheed 3.3.0 (GTK+ 2.24.19; 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.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Sep 2013 08:18:20 -0000 I compiled stm32flash[1] under FreeBSD 8.4-STABLE: tingo@kg-core1$ uname -a FreeBSD kg-core1.kg4.no 8.4-STABLE FreeBSD 8.4-STABLE #0 r253646: Thu Jul 25 10:12:31 UTC 2013 root@kg-core1.kg4.no:/usr/obj/usr/src/sys/GENERIC amd64 The resulting binary appears to work: tingo@kg-core1$ ./stm32flash stm32flash - http://stm32flash.googlecode.com/ ERROR: Device not specified Usage: ./stm32flash [-bvngfhc] [-[rw] filename] /dev/ttyS0 -b rate Baud rate (default 57600) -r filename Read flash to file -w filename Write flash to file -u Disable the flash write-protection -e n Only erase n pages before writing the flash -v Verify writes -n count Retry failed writes up to count times (default 10) -g address Start execution at specified address (0 = flash start) -f Force binary parser -h Show this help -c Resume the connection (don't send initial INIT) *Baud rate must be kept the same as the first init* This is useful if the reset fails I have an STM32 board connected to cuaU0/ttyU0: tingo@kg-core1$ ls -l /dev/cuaU* /dev/ttyU* crw-rw---- 1 uucp operator 0, 159 Aug 18 17:26 /dev/cuaU0 crw-rw---- 1 uucp operator 0, 160 Aug 18 17:26 /dev/cuaU0.init crw-rw---- 1 uucp operator 0, 161 Aug 18 17:26 /dev/cuaU0.lock crw-rw---- 1 root operator 0, 156 Aug 18 17:26 /dev/ttyU0 crw-rw---- 1 root operator 0, 157 Aug 18 17:26 /dev/ttyU0.init crw-rw---- 1 root operator 0, 158 Aug 18 17:26 /dev/ttyU0.lock and my user has access: tingo@kg-core1$ id uid=1001(tingo) gid=1001(users) groups=1001(users),0(wheel),5(operator) Still it doesn't work: tingo@kg-core1$ ./stm32flash /dev/cuaU0 stm32flash - http://stm32flash.googlecode.com/ /dev/cuaU0: No such file or directory tingo@kg-core1$ ./stm32flash /dev/ttyU0 stm32flash - http://stm32flash.googlecode.com/ /dev/ttyU0: No such file or directory t doesn't work as root either, so it doesn't look like a permissions problem. BTW, stm32flash with the same board and cable works nicely under Linux. Any hints on what could be wrong? References: 1) http://code.google.com/p/stm32flash/ -- Torfinn Ingolfsen From owner-freebsd-arm@FreeBSD.ORG Wed Sep 18 12:53:47 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 7174EE6D for ; Wed, 18 Sep 2013 12:53:47 +0000 (UTC) (envelope-from ronald-freebsd8@klop.yi.org) Received: from cpsmtpb-ews01.kpnxchange.com (cpsmtpb-ews01.kpnxchange.com [213.75.39.4]) by mx1.freebsd.org (Postfix) with ESMTP id D68C227BF for ; Wed, 18 Sep 2013 12:53:46 +0000 (UTC) Received: from cpsps-ews11.kpnxchange.com ([10.94.84.178]) by cpsmtpb-ews01.kpnxchange.com with Microsoft SMTPSVC(7.5.7601.17514); Wed, 18 Sep 2013 14:52:35 +0200 Received: from CPSMTPM-TLF101.kpnxchange.com ([195.121.3.4]) by cpsps-ews11.kpnxchange.com with Microsoft SMTPSVC(7.5.7601.17514); Wed, 18 Sep 2013 14:52:35 +0200 Received: from sjakie.klop.ws ([212.182.167.131]) by CPSMTPM-TLF101.kpnxchange.com with Microsoft SMTPSVC(7.5.7601.17514); Wed, 18 Sep 2013 14:52:35 +0200 Received: from 212-182-167-131.ip.telfort.nl (localhost [127.0.0.1]) by sjakie.klop.ws (Postfix) with ESMTP id 22D0576E2 for ; Wed, 18 Sep 2013 14:52:31 +0200 (CEST) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes To: freebsd-arm@freebsd.org Subject: Re: Panic while building perl on sheevaplug/armv5 freebsd 10. References: <1379080987.1111.637.camel@revolution.hippie.lan> Date: Wed, 18 Sep 2013 14:52:22 +0200 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Ronald Klop" Message-ID: In-Reply-To: User-Agent: Opera Mail/12.16 (FreeBSD) X-OriginalArrivalTime: 18 Sep 2013 12:52:35.0671 (UTC) FILETIME=[F2B50E70:01CEB46D] X-RcptDomain: freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Sep 2013 12:53:47 -0000 On Sun, 15 Sep 2013 15:31:50 +0200, Ronald Klop wrote: > On Fri, 13 Sep 2013 16:03:07 +0200, Ian Lepore wrote: > >> On Fri, 2013-09-13 at 15:11 +0200, Ronald Klop wrote: >>> Hello, >>> >>> I have a repeatable panic while building perl on my Sheevaplug ARMv5 >>> running FreeBSD 10-CURRENT. >>> Kernel is loaded from NAND. >>> / is mounted from USB /dev/da0s2 (UFS2) >>> /usr/ports is mounted over NFS from a 9-STABLE/amd64 box. >>> Swap from 512MB file in /data/swap. >>> >>> ---- console output >>> login: panic: vm_fault: fault on nofault entry, addr: ddf9d000 >>> KDB: enter: panic >>> [ thread pid 659 tid 100057 ] >>> Stopped at kdb_enter+0x4c: ldrb r15, [r15, r15, ror r15]! >>> db> bt >>> Tracing pid 659 tid 100057 td 0xc3f86000 >> [...] >>> exception_exit() at exception_exit >>> pc = 0xc0bba3fc lr = 0xc0a60c88 (tc_setclock+0x458) >>> sp = 0xddf9d008 fp = 0xddf9e038 >>> r0 = 0xc0bba324 r1 = 0xc0d00000 >>> r2 = 0xddf9d00c r3 = 0x20000093 >>> r4 = 0x00000000 r5 = 0xc0ccd630 >>> r6 = 0x00000000 r7 = 0x00000000 >>> r8 = 0xc0caece0 r9 = 0x00000001 >>> r10 = 0xc0caec88 r12 = 0x00000000 >>> data_abort_entry() at data_abort_entry+0x30 >>> pc = 0xc0bba324 lr = 0xc0a60c88 (tc_setclock+0x458) >>> sp = 0xddf9d008 fp = 0xddf9e038 >>> Unwind failure (no registers changed) >> >> That's the second time in the past few months I've seen a backtrace that >> makes it look like we ran out of kernel stack, but the default is 8k >> which should be plenty. Still, try adding "option KSTACK_PAGES=3" to >> your kernel config and see if the problem goes away. If it does, we may >> need to figure out why we're using so much stack. If it doesn't, we've >> probably got a bad recursion loop happening somewhere. >> >> -- Ian >> > > I had to bump KSTACK_PAGES up to 4, but now it is going on with building > ports. > I still have similar faults (but less of them) with 4. panic: vm_fault: fault on nofault entry, addr: de038000 KDB: enter: panic [ thread pid 2834 tid 100066 ] Stopped at kdb_enter+0x4c: ldrb r15, [r15, r15, ror r15]! db> reboot Running with KSTACK_PAGES=5 now. Ronald. From owner-freebsd-arm@FreeBSD.ORG Wed Sep 18 17:03:10 2013 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id AA6D1B00 for ; Wed, 18 Sep 2013 17:03:10 +0000 (UTC) (envelope-from ian@FreeBSD.org) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 7F250279B for ; Wed, 18 Sep 2013 17:03:10 +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 1VMHza-000Jk2-1j; Wed, 18 Sep 2013 13:40:30 +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 r8IDeQeF014965; Wed, 18 Sep 2013 07:40:26 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX18kw3rLz/tvTkl0TGMEem11 Subject: Re: stm32flash under FreeBSD? From: Ian Lepore To: Torfinn Ingolfsen In-Reply-To: <20130918101235.e1737d4bd839f71ebf554803@getmail.no> References: <20130918101235.e1737d4bd839f71ebf554803@getmail.no> Content-Type: text/plain; charset="us-ascii" Date: Wed, 18 Sep 2013 07:40:26 -0600 Message-ID: <1379511626.1197.69.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-arm@FreeBSD.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Sep 2013 17:03:10 -0000 On Wed, 2013-09-18 at 10:12 +0200, Torfinn Ingolfsen wrote: > I compiled stm32flash[1] under FreeBSD 8.4-STABLE: > tingo@kg-core1$ uname -a > FreeBSD kg-core1.kg4.no 8.4-STABLE FreeBSD 8.4-STABLE #0 r253646: Thu Jul 25 10:12:31 UTC 2013 > root@kg-core1.kg4.no:/usr/obj/usr/src/sys/GENERIC amd64 > > The resulting binary appears to work: > tingo@kg-core1$ ./stm32flash > stm32flash - http://stm32flash.googlecode.com/ > > ERROR: Device not specified > Usage: ./stm32flash [-bvngfhc] [-[rw] filename] /dev/ttyS0 > -b rate Baud rate (default 57600) > -r filename Read flash to file > -w filename Write flash to file > -u Disable the flash write-protection > -e n Only erase n pages before writing the flash > -v Verify writes > -n count Retry failed writes up to count times (default 10) > -g address Start execution at specified address (0 = flash start) > -f Force binary parser > -h Show this help > -c Resume the connection (don't send initial INIT) > *Baud rate must be kept the same as the first init* > This is useful if the reset fails > > I have an STM32 board connected to cuaU0/ttyU0: > tingo@kg-core1$ ls -l /dev/cuaU* /dev/ttyU* > crw-rw---- 1 uucp operator 0, 159 Aug 18 17:26 /dev/cuaU0 > crw-rw---- 1 uucp operator 0, 160 Aug 18 17:26 /dev/cuaU0.init > crw-rw---- 1 uucp operator 0, 161 Aug 18 17:26 /dev/cuaU0.lock > crw-rw---- 1 root operator 0, 156 Aug 18 17:26 /dev/ttyU0 > crw-rw---- 1 root operator 0, 157 Aug 18 17:26 /dev/ttyU0.init > crw-rw---- 1 root operator 0, 158 Aug 18 17:26 /dev/ttyU0.lock > > and my user has access: > tingo@kg-core1$ id > uid=1001(tingo) gid=1001(users) groups=1001(users),0(wheel),5(operator) > > Still it doesn't work: > tingo@kg-core1$ ./stm32flash /dev/cuaU0 > stm32flash - http://stm32flash.googlecode.com/ > > /dev/cuaU0: No such file or directory > tingo@kg-core1$ ./stm32flash /dev/ttyU0 > stm32flash - http://stm32flash.googlecode.com/ > > /dev/ttyU0: No such file or directory > > t doesn't work as root either, so it doesn't look like a permissions problem. > > BTW, stm32flash with the same board and cable works nicely under Linux. Any hints on what could be wrong? > > References: > 1) http://code.google.com/p/stm32flash/ With a quick glance at the stm32flash source I'm not seeing anything unusual about the way it handles the serial port. It might be useful to try "truss ./stm32flash /dev/cuaU0" and see what call it fails on and what the call args are. -- Ian From owner-freebsd-arm@FreeBSD.ORG Wed Sep 18 17:57:53 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 068FCF9B for ; Wed, 18 Sep 2013 17:57:53 +0000 (UTC) (envelope-from bounces+1118583.103798401.388224@icpbounce.com) Received: from drone3.rtp.icpbounce.com (drone3.rtp.icpbounce.com [74.202.227.43]) by mx1.freebsd.org (Postfix) with ESMTP id 983432AFD for ; Wed, 18 Sep 2013 17:57:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; s=default; d=icontactmail1.com; h=Mime-Version:From:To:Date:Subject:List-Unsubscribe:Content-Type:Message-ID; bh=EaUiZr40fgQfIwOPrbSHKXTyM3w=; b=p+55wXp/4Nm1OF2vZkyYfWglu0MPs33dPnXn8ClpN/xMyQWjDPQ6Z3uf9+dY0q3RbTtT8OiYp+T1 sFCcTDRNeUpYSceLUrYUWMi5hAyebc2kiSqZ62Gy6SEdfU/Wg5PR8HR8mithNgQsDcHan2mXrYdi skmS9e3jcIlR8f84u1Q= Mime-Version: 1.0 From: "Scott Brown" To: Date: Wed, 18 Sep 2013 13:37:16 -0400 Subject: Purchase Order & Working Capital Errors-To: bounces+1118583.103798401.388224@icpbounce.com X-List-Unsubscribe: X-Unsubscribe-Web: X-ICPINFO: X-Return-Path-Hint: bounces+1118583.103798401.388224@icpbounce.com Message-ID: <0.1.357.4A0.1CEB495B7B3E8B4.0@drone3.rtp.icpbounce.com> Content-Type: text/plain; charset = "utf-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Sep 2013 17:57:53 -0000 * I've recently been blessed to be able to help several banks , CPA's and= =0Alending institutions with their clients cash flow needs where the clien= t was=0Anot yet bankable or the bank needed an exit strategy from existing = revolvers.=0A=0AFeel fee to call me or email if I can answer any questions.= =0A=0AScott=0A=0ACreative Working Capital Factoring=0A=0APurchase Order Fin= ancing=0A=0A[1]www.MidlandAmericanCapital.com=0A=0AScott P Brown = 11175 Cicero Dr ~ Ste 100=0A=0A(770) 880-9208 = Alpharetta, GA=0A30022=0A=0Asbrown@= midlandamericancapital.com=0A=0A(3) Recent Purchase Order Transactions=0A= =0ABelow are just a few examples of recent Purchase Order financings we hav= e=0Acompleted. If you or someone you know needs Working Capital, or Funding= for a=0Asingle or multiple ongoing Purchase Orders - give me a call at (77= 0) 880-9208.=0ABest - Scott.=0A=0AAmmunition Manufacturer=0A=0APurchase Ord= er=0A=0A&=0A=0AAccounts Receivable=0A=0A$ 500,000=0A=0ACompany in the Carol= inas manufacturers custom and branded ammunition in various=0Acalibers. The= y sell to major chain Athletic stores, U.S. Government, and Gun=0AStores th= roughout the U.S.=0A=0AMain Concerns Solved:=0A* Purchase or Brass and GunP= owder QUICKLY when it becomes available=0A* Speed of reacting to incoming o= rders=0A* Unique Product=0A* Regulations=0A=0AI.T. Sales & Service Company= =0A=0APurchase Order=0A=0A&=0A=0AAccounts Receivable=0A=0A$ 900,000=0A=0APr= ovided a Purchase Order facility offering 100% funding of all purchase cost= s=0Aof computers to fill orders, using an Int'l Letter of Credit to supplie= r.=0ACompany was able to fill orders quickly, and with security having not = forwarded=0Acash overseas.=0A=0AMain Concerns Solved:=0A* Funding 100% of c= osts to supplier - not the 70% our competitors offer=0A* Sending deposits a= nd final payment overseas without goods being inspected=0A=0ABoiler Repair = & Installation Service Company=0A=0AAccounts Receivable=0A=0A$500,000=0A=0A= Provided a Working Capital line so that upon invocing at completion of serv= ice,=0Athe company could draw on it's Accounts Receivable for Payroll and o= ther costs=0Aalong the way before payments would be received from Net 30 bi= lling.=0A=0AMain Concerns Solved:=0A* Payroll - on time - Weekly=0A* Vendor= s and Supply Chain paid timely for parts=0A* Payroll Taxes=0A* Maintain Ove= rhaed payments timely=0A=0AIf you or your client needs Purchase Order Finan= cing, or Non-Invasive Factoring=0Aplease don't hesitate to contact me. I am= always enthusiastic to help.=0A=0ARegards,=0A=0AScott Brown=0A=0A(770) 880= -9208=0A=0Asbrown@midlandamericancapital.com=0A=0Awww.MidlandAmericanCapita= l.com=0A=0AWhat makes us Different?=0A=0AA Lot ! We are different from othe= r providers in that we remove all the barriers=0Ato great service, and neve= r require our clients to sign a term commitment or pay=0Aexit fees.=0A=0ACo= mpetitors Midland=0A=0A[2]=0A=0AJoin me on Linked=0A=0Awww.MidlandA= mericanCapital.com=0A=0APhone: 770-880-9208 SBrown@mindlandAmericanCapita= l.com=0A=0AReferences=0A=0A1. http://www.MidlandAmericanCapital.com/=0A2. h= ttp://www.linkedin.com/in/scottprestonbrown/=0A=0AThis message was sent to freebsd-arm@freebsd.org from: Midland American Capital | 6470 Ga Hwy 400 S.E. Financial Center | Cumming, GA 30028=0A=0AUnsubscribe:=0Ahttp://app.icontact.com/icp/mmail-mprofile.pl?r=3D103798401&l=3D10242&s=3DUQGY&m=3D388224&c=3D1118583=0A=0A=0A From owner-freebsd-arm@FreeBSD.ORG Wed Sep 18 19:57:43 2013 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 1F579990 for ; Wed, 18 Sep 2013 19:57:43 +0000 (UTC) (envelope-from torfinn.ingolfsen@getmail.no) Received: from galore.getmail.no (galore.getmail.no [84.210.184.6]) by mx1.freebsd.org (Postfix) with ESMTP id B35932283 for ; Wed, 18 Sep 2013 19:57:42 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by galore.getmail.no (Postfix) with ESMTP id 4A77014501A for ; Wed, 18 Sep 2013 21:52:24 +0200 (CEST) X-Spam-Flag: NO X-Spam-Score: -2.94 X-Spam-Level: X-Spam-Status: No, score=-2.94 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_FB_WORD2_END_DOLLAR=0.01, T_KHOP_THREADED=-0.01, T_NICE_REPLY_A=0.01, T_TVD_SUBJ_NUM_OBFU=0.01, T_TVD_SUBJ_NUM_OBFU2=0.01, T_TVD_SUBJ_NUM_OBFU3=0.01, T_UNKNOWN_ORIGIN=0.01, T_UPPERCASE_URI=0.01] autolearn=ham Authentication-Results: galore.get.c.bitbit.net (amavisd-new); dkim=pass (1024-bit key) header.d=getmail.no Received: from galore.getmail.no ([127.0.0.1]) by localhost (galore.get.c.bitbit.net [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id 9G2s6_eC54As for ; Wed, 18 Sep 2013 21:52:23 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by galore.getmail.no (Postfix) with ESMTP id A25C614502B for ; Wed, 18 Sep 2013 21:52:23 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.7.1 galore.getmail.no A25C614502B DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=getmail.no; s=8A9C8B4C-D727-11E2-8095-B6466E6B3FA2; t=1379533943; bh=o85fI372/fl/zSupq5nvAnBf4A0e3CvIbvA6mvJqVlk=; h=Date:From:To:Subject:Message-Id:Mime-Version:Content-Type: Content-Transfer-Encoding; b=Z7PqDzKmGcwSVDY9ZlASm43hzVi8JxDBU9lr0vSrnTTy7eLihX/2MD4dIikUi84WV ZxcveW9nl4zNYMzJXpaOrGG5w3swtI19ZfcMTILxEbYsshBntVdYDVrNkIL28bdljK e/LpF/r/Z9meLmcAvprchD+mspwAiAigcM1Cs6fM= X-Virus-Scanned: amavisd-new at Received: from galore.getmail.no ([127.0.0.1]) by localhost (galore.get.c.bitbit.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id RmHLL86Q75qC for ; Wed, 18 Sep 2013 21:52:23 +0200 (CEST) Received: from kg-core1.kg4.no (cm-84.215.180.206.getinternet.no [84.215.180.206]) by galore.getmail.no (Postfix) with ESMTPSA id 7679114501A for ; Wed, 18 Sep 2013 21:52:23 +0200 (CEST) Date: Wed, 18 Sep 2013 21:52:17 +0200 From: Torfinn Ingolfsen To: freebsd-arm@FreeBSD.org Subject: Re: stm32flash under FreeBSD? Message-Id: <20130918215217.24905fd7f91523a0b70170b5@getmail.no> In-Reply-To: <1379511626.1197.69.camel@revolution.hippie.lan> References: <20130918101235.e1737d4bd839f71ebf554803@getmail.no> <1379511626.1197.69.camel@revolution.hippie.lan> X-Mailer: Sylpheed 3.3.0 (GTK+ 2.24.19; 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.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Sep 2013 19:57:43 -0000 On Wed, 18 Sep 2013 07:40:26 -0600 Ian Lepore wrote: > > With a quick glance at the stm32flash source I'm not seeing anything > unusual about the way it handles the serial port. It might be useful to > try "truss ./stm32flash /dev/cuaU0" and see what call it fails on and > what the call args are. I always forget about truss - thanks for reminding me. Unfortunately, I can't make anything out of the output from truss, nothing here "pops out" to me. Maybe more trained eyes than mine can spot something: tingo@kg-core1$ truss ./stm32flash /dev/cuaU0 __sysctl(0x7fffffffe070,0x2,0x7fffffffe08c,0x7fffffffe080,0x0,0x0) = 0 (0x0) mmap(0x0,688,PROT_READ|PROT_WRITE,MAP_ANON,-1,0x0) = 34365198336 (0x800535000) munmap(0x800535000,688) = 0 (0x0) __sysctl(0x7fffffffe0e0,0x2,0x80063f408,0x7fffffffe0d8,0x0,0x0) = 0 (0x0) mmap(0x0,32768,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0) = 34365198336 (0x800535000) issetugid(0x800536015,0x800530684,0x80064bb10,0x80064bae0,0x5991,0x0) = 0 (0x0) open("/etc/libmap.conf",O_RDONLY,0666) ERR#2 'No such file or directory' open("/var/run/ld-elf.so.hints",O_RDONLY,057) = 3 (0x3) read(3,"Ehnt\^A\0\0\0\M^@\0\0\0002\^A\0"...,128) = 128 (0x80) lseek(3,0x80,SEEK_SET) = 128 (0x80) read(3,"/lib:/usr/lib:/usr/lib/compat:/u"...,306) = 306 (0x132) close(3) = 0 (0x0) access("/lib/libc.so.7",0) = 0 (0x0) open("/lib/libc.so.7",O_RDONLY,030771340) = 3 (0x3) fstat(3,{ mode=-r--r--r-- ,inode=5537727,size=1298464,blksize=32768 }) = 0 (0x0) pread(0x3,0x80063e2c0,0x1000,0x0,0x101010101010101,0x8080808080808080) = 4096 (0x1000) mmap(0x0,2371584,PROT_NONE,MAP_PRIVATE|MAP_ANON|MAP_NOCORE,-1,0x0) = 34366341120 (0x80064c000) mmap(0x80064c000,1085440,PROT_READ|PROT_EXEC,MAP_PRIVATE|MAP_FIXED|MAP_NOCORE,3,0x0) = 34366341120 (0x80064c000) mmap(0x800855000,126976,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_FIXED,3,0x109000) = 34368475136 (0x800855000) mmap(0x800874000,110592,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_FIXED|MAP_ANON,-1,0x0) = 34368602112 (0x800874000) close(3) = 0 (0x0) mmap(0x0,656,PROT_READ|PROT_WRITE,MAP_ANON,-1,0x0) = 34365231104 (0x80053d000) munmap(0x80053d000,656) = 0 (0x0) mmap(0x0,43904,PROT_READ|PROT_WRITE,MAP_ANON,-1,0x0) = 34365231104 (0x80053d000) munmap(0x80053d000,43904) = 0 (0x0) sysarch(0x81,0x7fffffffe160,0x800539088,0x0,0xffffffffffcde450,0x8080808080808080) = 0 (0x0) sigprocmask(SIG_BLOCK,SIGHUP|SIGINT|SIGQUIT|SIGKILL|SIGPIPE|SIGALRM|SIGTERM|SIGURG|SIGSTOP|SIGTSTP|SIGCONT|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGXCPU|SIGXFSZ|SIGVTALRM|SIGPROF|SIGWINCH|SIGINFO|SIGUSR1|SIGUSR2,0x0) = 0 (0x0) sigprocmask(SIG_SETMASK,0x0,0x0) = 0 (0x0) __sysctl(0x7fffffffe0f0,0x2,0x80087a780,0x7fffffffe0e8,0x0,0x0) = 0 (0x0) sigprocmask(SIG_BLOCK,SIGHUP|SIGINT|SIGQUIT|SIGKILL|SIGPIPE|SIGALRM|SIGTERM|SIGURG|SIGSTOP|SIGTSTP|SIGCONT|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGXCPU|SIGXFSZ|SIGVTALRM|SIGPROF|SIGWINCH|SIGINFO|SIGUSR1|SIGUSR2,0x0) = 0 (0x0) sigprocmask(SIG_SETMASK,0x0,0x0) = 0 (0x0) fstat(1,{ mode=crw--w---- ,inode=147,size=0,blksize=4096 }) = 0 (0x0) __sysctl(0x7fffffffe0b0,0x2,0x800879dc8,0x7fffffffe0a8,0x0,0x0) = 0 (0x0) __sysctl(0x7fffffffdfd0,0x2,0x7fffffffdf60,0x7fffffffdfc8,0x8007478c0,0xc) = 0 (0x0) __sysctl(0x7fffffffdf60,0x2,0x800879fd0,0x7fffffffe028,0x0,0x0) = 0 (0x0) readlink("/etc/malloc.conf",0x7fffffffe0d0,1024) ERR#2 'No such file or directory' issetugid(0x800746581,0x7fffffffe0d0,0xffffffffffffffff,0x0,0x2,0x0) = 0 (0x0) break(0x600000) = 0 (0x0) __sysctl(0x7fffffffe360,0x2,0x7fffffffe37c,0x7fffffffe370,0x0,0x0) = 0 (0x0) mmap(0x0,2097152,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0) = 34368712704 (0x80088f000) mmap(0x800a8f000,1511424,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0) = 34370809856 (0x800a8f000) munmap(0x80088f000,1511424) = 0 (0x0) ioctl(1,TIOCGETA,0xffffe540) = 0 (0x0) stm32flash - http://stm32flash.googlecode.com/ write(1,"stm32flash - http://stm32flash.g"...,47) = 47 (0x2f) write(1,"\n",1) = 1 (0x1) open("/dev/cuaU0",O_RDWR|O_NONBLOCK|O_NOCTTY,00) = 3 (0x3) fcntl(3,F_SETFL,0x0) = 0 (0x0) ioctl(3,TIOCGETA,0xa07084) = 0 (0x0) ioctl(3,TIOCGETA,0xa070b0) = 0 (0x0) ioctl(3,TIOCFLUSH,0xffffe5c4) = 0 (0x0) ioctl(3,TIOCSETA,0xa070b0) = 0 (0x0) ioctl(3,TIOCGETA,0xffffe620) = 0 (0x0) stat("/usr/share/nls/C/libc.cat",0x7fffffffd8b0) ERR#2 'No such file or directory' stat("/usr/share/nls/libc/C",0x7fffffffd8b0) ERR#2 'No such file or directory' stat("/usr/local/share/nls/C/libc.cat",0x7fffffffd8b0) ERR#2 'No such file or directory' stat("/usr/local/share/nls/libc/C",0x7fffffffd8b0) ERR#2 'No such file or directory' /dev/cuaU0: No such file or directory writev(0x2,0x7fffffffddf0,0x4,0x19,0x1b4664,0x800a00128) = 38 (0x26) ioctl(3,TIOCFLUSH,0xffffe624) = 0 (0x0) ioctl(3,TIOCSETA,0xa07084) = 0 (0x0) close(3) = 0 (0x0) write(1,"\n",1) = 1 (0x1) sigprocmask(SIG_BLOCK,SIGHUP|SIGINT|SIGQUIT|SIGKILL|SIGPIPE|SIGALRM|SIGTERM|SIGURG|SIGSTOP|SIGTSTP|SIGCONT|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGXCPU|SIGXFSZ|SIGVTALRM|SIGPROF|SIGWINCH|SIGINFO|SIGUSR1|SIGUSR2,0x0) = 0 (0x0) sigprocmask(SIG_SETMASK,0x0,0x0) = 0 (0x0) sigprocmask(SIG_BLOCK,SIGHUP|SIGINT|SIGQUIT|SIGKILL|SIGPIPE|SIGALRM|SIGTERM|SIGURG|SIGSTOP|SIGTSTP|SIGCONT|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGXCPU|SIGXFSZ|SIGVTALRM|SIGPROF|SIGWINCH|SIGINFO|SIGUSR1|SIGUSR2,0x0) = 0 (0x0) sigprocmask(SIG_SETMASK,0x0,0x0) = 0 (0x0) process exit, rval = 1 -- Torfinn Ingolfsen From owner-freebsd-arm@FreeBSD.ORG Thu Sep 19 00:03:04 2013 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 308E9900 for ; Thu, 19 Sep 2013 00:03:04 +0000 (UTC) (envelope-from ian@FreeBSD.org) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id E8AF92E50 for ; Thu, 19 Sep 2013 00:03:03 +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 1VMRhx-000Fiz-BN; Thu, 19 Sep 2013 00:02:57 +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 r8J02sf7015406; Wed, 18 Sep 2013 18:02:54 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX18sxhwnhnTeRsCBxVGmmJso Subject: Re: stm32flash under FreeBSD? From: Ian Lepore To: Torfinn Ingolfsen In-Reply-To: <20130918215217.24905fd7f91523a0b70170b5@getmail.no> References: <20130918101235.e1737d4bd839f71ebf554803@getmail.no> <1379511626.1197.69.camel@revolution.hippie.lan> <20130918215217.24905fd7f91523a0b70170b5@getmail.no> Content-Type: text/plain; charset="us-ascii" Date: Wed, 18 Sep 2013 18:02:53 -0600 Message-ID: <1379548973.1197.76.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-arm@FreeBSD.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Sep 2013 00:03:04 -0000 On Wed, 2013-09-18 at 21:52 +0200, Torfinn Ingolfsen wrote: > On Wed, 18 Sep 2013 07:40:26 -0600 > Ian Lepore wrote: > > > > > With a quick glance at the stm32flash source I'm not seeing anything > > unusual about the way it handles the serial port. It might be useful to > > try "truss ./stm32flash /dev/cuaU0" and see what call it fails on and > > what the call args are. > > I always forget about truss - thanks for reminding me. > Unfortunately, I can't make anything out of the output from truss, nothing here "pops out" to me. > Maybe more trained eyes than mine can spot something: > tingo@kg-core1$ truss ./stm32flash /dev/cuaU0 > __sysctl(0x7fffffffe070,0x2,0x7fffffffe08c,0x7fffffffe080,0x0,0x0) = 0 (0x0) > mmap(0x0,688,PROT_READ|PROT_WRITE,MAP_ANON,-1,0x0) = 34365198336 (0x800535000) > munmap(0x800535000,688) = 0 (0x0) > __sysctl(0x7fffffffe0e0,0x2,0x80063f408,0x7fffffffe0d8,0x0,0x0) = 0 (0x0) > mmap(0x0,32768,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0) = 34365198336 (0x800535000) > issetugid(0x800536015,0x800530684,0x80064bb10,0x80064bae0,0x5991,0x0) = 0 (0x0) > open("/etc/libmap.conf",O_RDONLY,0666) ERR#2 'No such file or directory' > open("/var/run/ld-elf.so.hints",O_RDONLY,057) = 3 (0x3) > read(3,"Ehnt\^A\0\0\0\M^@\0\0\0002\^A\0"...,128) = 128 (0x80) > lseek(3,0x80,SEEK_SET) = 128 (0x80) > read(3,"/lib:/usr/lib:/usr/lib/compat:/u"...,306) = 306 (0x132) > close(3) = 0 (0x0) > access("/lib/libc.so.7",0) = 0 (0x0) > open("/lib/libc.so.7",O_RDONLY,030771340) = 3 (0x3) > fstat(3,{ mode=-r--r--r-- ,inode=5537727,size=1298464,blksize=32768 }) = 0 (0x0) > pread(0x3,0x80063e2c0,0x1000,0x0,0x101010101010101,0x8080808080808080) = 4096 (0x1000) > mmap(0x0,2371584,PROT_NONE,MAP_PRIVATE|MAP_ANON|MAP_NOCORE,-1,0x0) = 34366341120 (0x80064c000) > mmap(0x80064c000,1085440,PROT_READ|PROT_EXEC,MAP_PRIVATE|MAP_FIXED|MAP_NOCORE,3,0x0) = 34366341120 (0x80064c000) > mmap(0x800855000,126976,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_FIXED,3,0x109000) = 34368475136 (0x800855000) > mmap(0x800874000,110592,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_FIXED|MAP_ANON,-1,0x0) = 34368602112 (0x800874000) > close(3) = 0 (0x0) > mmap(0x0,656,PROT_READ|PROT_WRITE,MAP_ANON,-1,0x0) = 34365231104 (0x80053d000) > munmap(0x80053d000,656) = 0 (0x0) > mmap(0x0,43904,PROT_READ|PROT_WRITE,MAP_ANON,-1,0x0) = 34365231104 (0x80053d000) > munmap(0x80053d000,43904) = 0 (0x0) > sysarch(0x81,0x7fffffffe160,0x800539088,0x0,0xffffffffffcde450,0x8080808080808080) = 0 (0x0) > sigprocmask(SIG_BLOCK,SIGHUP|SIGINT|SIGQUIT|SIGKILL|SIGPIPE|SIGALRM|SIGTERM|SIGURG|SIGSTOP|SIGTSTP|SIGCONT|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGXCPU|SIGXFSZ|SIGVTALRM|SIGPROF|SIGWINCH|SIGINFO|SIGUSR1|SIGUSR2,0x0) = 0 (0x0) > sigprocmask(SIG_SETMASK,0x0,0x0) = 0 (0x0) > __sysctl(0x7fffffffe0f0,0x2,0x80087a780,0x7fffffffe0e8,0x0,0x0) = 0 (0x0) > sigprocmask(SIG_BLOCK,SIGHUP|SIGINT|SIGQUIT|SIGKILL|SIGPIPE|SIGALRM|SIGTERM|SIGURG|SIGSTOP|SIGTSTP|SIGCONT|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGXCPU|SIGXFSZ|SIGVTALRM|SIGPROF|SIGWINCH|SIGINFO|SIGUSR1|SIGUSR2,0x0) = 0 (0x0) > sigprocmask(SIG_SETMASK,0x0,0x0) = 0 (0x0) > fstat(1,{ mode=crw--w---- ,inode=147,size=0,blksize=4096 }) = 0 (0x0) > __sysctl(0x7fffffffe0b0,0x2,0x800879dc8,0x7fffffffe0a8,0x0,0x0) = 0 (0x0) > __sysctl(0x7fffffffdfd0,0x2,0x7fffffffdf60,0x7fffffffdfc8,0x8007478c0,0xc) = 0 (0x0) > __sysctl(0x7fffffffdf60,0x2,0x800879fd0,0x7fffffffe028,0x0,0x0) = 0 (0x0) > readlink("/etc/malloc.conf",0x7fffffffe0d0,1024) ERR#2 'No such file or directory' > issetugid(0x800746581,0x7fffffffe0d0,0xffffffffffffffff,0x0,0x2,0x0) = 0 (0x0) > break(0x600000) = 0 (0x0) > __sysctl(0x7fffffffe360,0x2,0x7fffffffe37c,0x7fffffffe370,0x0,0x0) = 0 (0x0) > mmap(0x0,2097152,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0) = 34368712704 (0x80088f000) > mmap(0x800a8f000,1511424,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0) = 34370809856 (0x800a8f000) > munmap(0x80088f000,1511424) = 0 (0x0) > ioctl(1,TIOCGETA,0xffffe540) = 0 (0x0) > stm32flash - http://stm32flash.googlecode.com/ > write(1,"stm32flash - http://stm32flash.g"...,47) = 47 (0x2f) > > write(1,"\n",1) = 1 (0x1) > open("/dev/cuaU0",O_RDWR|O_NONBLOCK|O_NOCTTY,00) = 3 (0x3) > fcntl(3,F_SETFL,0x0) = 0 (0x0) > ioctl(3,TIOCGETA,0xa07084) = 0 (0x0) > ioctl(3,TIOCGETA,0xa070b0) = 0 (0x0) > ioctl(3,TIOCFLUSH,0xffffe5c4) = 0 (0x0) > ioctl(3,TIOCSETA,0xa070b0) = 0 (0x0) > ioctl(3,TIOCGETA,0xffffe620) = 0 (0x0) > stat("/usr/share/nls/C/libc.cat",0x7fffffffd8b0) ERR#2 'No such file or directory' > stat("/usr/share/nls/libc/C",0x7fffffffd8b0) ERR#2 'No such file or directory' > stat("/usr/local/share/nls/C/libc.cat",0x7fffffffd8b0) ERR#2 'No such file or directory' > stat("/usr/local/share/nls/libc/C",0x7fffffffd8b0) ERR#2 'No such file or directory' > /dev/cuaU0: No such file or directory > writev(0x2,0x7fffffffddf0,0x4,0x19,0x1b4664,0x800a00128) = 38 (0x26) > ioctl(3,TIOCFLUSH,0xffffe624) = 0 (0x0) > ioctl(3,TIOCSETA,0xa07084) = 0 (0x0) > close(3) = 0 (0x0) > > write(1,"\n",1) = 1 (0x1) > sigprocmask(SIG_BLOCK,SIGHUP|SIGINT|SIGQUIT|SIGKILL|SIGPIPE|SIGALRM|SIGTERM|SIGURG|SIGSTOP|SIGTSTP|SIGCONT|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGXCPU|SIGXFSZ|SIGVTALRM|SIGPROF|SIGWINCH|SIGINFO|SIGUSR1|SIGUSR2,0x0) = 0 (0x0) > sigprocmask(SIG_SETMASK,0x0,0x0) = 0 (0x0) > sigprocmask(SIG_BLOCK,SIGHUP|SIGINT|SIGQUIT|SIGKILL|SIGPIPE|SIGALRM|SIGTERM|SIGURG|SIGSTOP|SIGTSTP|SIGCONT|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGXCPU|SIGXFSZ|SIGVTALRM|SIGPROF|SIGWINCH|SIGINFO|SIGUSR1|SIGUSR2,0x0) = 0 (0x0) > sigprocmask(SIG_SETMASK,0x0,0x0) = 0 (0x0) > process exit, rval = 1 > > It looks to me like it's complaining about not finding libc's nls files (which I would think would be in /usr/local/share), as if a required port is missing or something. Or maybe ports with conflicting NLS options are installed. Then it mangles the error reporting to make it look like the tty device was the thing not found. -- Ian From owner-freebsd-arm@FreeBSD.ORG Thu Sep 19 11:45:32 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id B4BEDA3E; Thu, 19 Sep 2013 11:45:32 +0000 (UTC) (envelope-from richard@inf.ed.ac.uk) Received: from treacle.ucs.ed.ac.uk (treacle.ucs.ed.ac.uk [129.215.16.102]) by mx1.freebsd.org (Postfix) with ESMTP id 417F127E3; Thu, 19 Sep 2013 11:45:27 +0000 (UTC) Received: from crunchie.inf.ed.ac.uk (crunchie.inf.ed.ac.uk [129.215.33.180]) by treacle.ucs.ed.ac.uk (8.13.8/8.13.4) with ESMTP id r8JB6tmi007719; Thu, 19 Sep 2013 12:06:59 +0100 (BST) Received: from macavity.inf.ed.ac.uk (macavity.inf.ed.ac.uk [129.215.197.221]) by crunchie.inf.ed.ac.uk (8.14.4/8.14.4) with ESMTP id r8JB6tFn000388; Thu, 19 Sep 2013 12:06:55 +0100 Received: by macavity.inf.ed.ac.uk (Postfix, from userid 26013) id 5F9E197257B; Thu, 19 Sep 2013 12:06:56 +0100 (BST) From: Richard Tobin Subject: Re: stm32flash under FreeBSD? To: Ian Lepore , Torfinn Ingolfsen In-Reply-To: Ian Lepore's message of Wed, 18 Sep 2013 18:02:53 -0600 X-Mailer: Ream 5.1.51-richard-mac Message-Id: <20130919110656.5F9E197257B@macavity.inf.ed.ac.uk> Date: Thu, 19 Sep 2013 12:06:56 +0100 (BST) X-Edinburgh-Scanned: at treacle.ucs.ed.ac.uk with MIMEDefang 2.60, Sophie, Sophos Anti-Virus, Clam AntiVirus Content-Type: text/plain MIME-Version: 1.0 Content-Disposition: inline X-Scanned-By: MIMEDefang 2.60 on 129.215.16.102 Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Sep 2013 11:45:32 -0000 > Then it mangles the error reporting to make it > look like the tty device was the thing not found. It appears to call perror(device) if serial_setup() returns an error, even though that can fail without setting errno. -- Richard -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. From owner-freebsd-arm@FreeBSD.ORG Thu Sep 19 12:48:08 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 42B03730 for ; Thu, 19 Sep 2013 12:48:08 +0000 (UTC) (envelope-from rrs@lakerest.net) Received: from lakerest.net (lakerest.net [70.155.160.98]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id C4F992B1D for ; Thu, 19 Sep 2013 12:48:07 +0000 (UTC) Received: from [10.1.1.103] (bsd4.lakerest.net [70.155.160.102]) (authenticated bits=0) by lakerest.net (8.14.4/8.14.3) with ESMTP id r8JCOnJ4049162 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Thu, 19 Sep 2013 08:24:52 -0400 (EDT) (envelope-from rrs@lakerest.net) From: Randall Stewart Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Subject: Trouble with a dream plug... Date: Thu, 19 Sep 2013 08:24:49 -0400 Message-Id: <3D3276E2-7436-4E98-A37D-1529C1752158@lakerest.net> To: ARM Mime-Version: 1.0 (Apple Message framework v1283) X-Mailer: Apple Mail (2.1283) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Sep 2013 12:48:08 -0000 Hi all: I am playing with a DreamPlug which has the marvell 88F6281 chip set in it: http://www.globalscaletechnologies.com/p-54-dreamplug-devkit.aspx The version number of this seems to be 3. When I first tried to bring it up following the wiki: https://wiki.freebsd.org/FreeBSDMarvell I had no joy, the system would boot up until it tried to find the = ethernet and die=85 So with a bit of playing I figured out that the miiphy was incorrect, it = was trying to use 8 and I found with a bit of poking that the two phys are on 0 and = 1 (There are two Marvell Gig-E's on this critter). Now after I got it to boot, I wanted to find a way to get the second = ethernet up. Linux (which comes with it of course) finds both of them so why can't I? So after digging some and learning about the flattened device tree, I = find that the layout of this in respect to the ether-net is as follows (reported by a modified ofwdump.. I had = to make it so that=20 it did not exit when it sees a next-prop return an error, evidently this = little arm just gives you an error, not a 0 back when you hit the end of the properties). = Anyway here is my=20 ethernet description: ********************************* Node 0x840: ethernet@72000 #address-cells: 00 00 00 01 #size-cells: 00 00 00 01 model: 56 32 00 'V2' compatible: 6d 72 76 6c 2c 67 65 00 'mrvl,ge' reg: 00 07 20 00 00 00 20 00 ranges: =20 00 00 00 00 00 07 20 00 00 00 20 00 local-mac-address: 00 00 00 00 00 00 interrupts: 00 00 00 0c 00 00 00 0d 00 00 00 0e 00 00 00 0b 00 00 00 2e interrupt-parent:=20 00 00 00 01 =20 phy-handle: =20 00 00 00 02 ------------Child of the E-net ------------ Node 0x918: mdio@0 #address-cells: 00 00 00 01 #size-cells: 00 00 00 00 compatible: 6d 72 76 6c 2c 6d 64 69 6f 00 'mrvl,mdio' ---------Child of the mdio ----------- Node 0x95c: ethernet-phy@0 reg: 00 00 00 08 phandle: 00 00 00 02 **************************** =46rom this you can see where the idea of the phy being at 8 is coming = from. Its sure enough is in the ethernet-phy. Now I am *not* sure what an mdio is = supposed to do for us, and even more strange is how does linux seem to be able to bring = up both ports on this? The spec's say that the first port is at 72000 - 73fff and the second is = at 76000 - 77fff. And of course with no FDT description we won't see it. Is our friend linux just assuming that its at those addresses? We end up = with a list of IRQ's there as well 0xb, 0xc, 0xd, 0xe an 0x2e. Linux uses 0xb = for eth0 and 0xf for eth1. Anyone out there familiar with why I can't see the second network? Is = this a bad fdt that came from the vendor? or do we need to just have driver = hacks in that "assume" the second one is there? If so I am not sure how to deal = with the IRQ's can we just allocate one? Linux seems fine with doing that unless there = is something I am missing in my limited understanding of the FDT stuff. Any pointers or hints would be appreciated. R ------------------------------ Randall Stewart 803-317-4952 (cell) From owner-freebsd-arm@FreeBSD.ORG Thu Sep 19 12:58:37 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 1DCF1CD6 for ; Thu, 19 Sep 2013 12:58:37 +0000 (UTC) (envelope-from ronald-freebsd8@klop.yi.org) Received: from cpsmtpb-ews03.kpnxchange.com (cpsmtpb-ews03.kpnxchange.com [213.75.39.6]) by mx1.freebsd.org (Postfix) with ESMTP id 821BD2C35 for ; Thu, 19 Sep 2013 12:58:36 +0000 (UTC) Received: from cpsps-ews20.kpnxchange.com ([10.94.84.186]) by cpsmtpb-ews03.kpnxchange.com with Microsoft SMTPSVC(7.5.7601.17514); Thu, 19 Sep 2013 14:57:26 +0200 Received: from CPSMTPM-TLF102.kpnxchange.com ([195.121.3.5]) by cpsps-ews20.kpnxchange.com with Microsoft SMTPSVC(7.5.7601.17514); Thu, 19 Sep 2013 14:57:26 +0200 Received: from sjakie.klop.ws ([212.182.167.131]) by CPSMTPM-TLF102.kpnxchange.com with Microsoft SMTPSVC(7.5.7601.17514); Thu, 19 Sep 2013 14:57:26 +0200 Received: from 212-182-167-131.ip.telfort.nl (localhost [127.0.0.1]) by sjakie.klop.ws (Postfix) with ESMTP id 060677B4D for ; Thu, 19 Sep 2013 14:57:25 +0200 (CEST) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes To: freebsd-arm@freebsd.org Subject: Re: svn on armv5 with clang? (Fwd: svn commit: r254539 - head/usr.bin) References: <201308191744.r7JHiJ00063824@svn.freebsd.org> <20130917190215.7093f261@bender.Home> Date: Thu, 19 Sep 2013 14:57:25 +0200 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Ronald Klop" Message-ID: In-Reply-To: <20130917190215.7093f261@bender.Home> User-Agent: Opera Mail/12.16 (FreeBSD) X-OriginalArrivalTime: 19 Sep 2013 12:57:26.0838 (UTC) FILETIME=[CAAB5D60:01CEB537] X-RcptDomain: freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Sep 2013 12:58:37 -0000 On Tue, 17 Sep 2013 20:02:15 +0200, Andrew Turner wrote: > On Tue, 17 Sep 2013 16:13:22 +0200 > "Ronald Klop" wrote: > >> Hi, >> >> I am reading up on commits and found this one. Is ARMv5 capable of >> building the in-tree svn also? >> > It is unlikely, I don't think we provide the required atomic functions > for ARMv5. On armv6 clang provides them, however I don't thing it knows > how to set up ARM_RAS_START. Without this we have to implement more of > the __sync_* functions for svn to work on ARMv5. I don't know of any > plans to add them. > > Andrew > I just tried it and you are right. For some mailinglist documentation I append the error here. Is this something for FreeBSD to add or for clang/llvm folks? Or a joint effort? Cheers, Ronald. cc -O -pipe -I/usr/src/usr.bin/svn/lib/libsvn_subr/../../../../contrib/subversion/subversion/include -I/usr/src/usr.bin/svn/lib/libsvn_subr/../../../../contrib/subversion/subversion -I/usr/src/usr.bin/svn/lib/libsvn_subr/../.. -I/usr/src/usr.bin/svn/lib/libsvn_subr/../libapr -I/usr/src/usr.bin/svn/lib/libsvn_subr/../../../../contrib/apr/include/arch/unix -I/usr/src/usr.bin/svn/lib/libsvn_subr/../../../../contrib/apr/include -I/usr/src/usr.bin/svn/lib/libsvn_subr/../libapr_util -I/usr/src/usr.bin/svn/lib/libsvn_subr/../../../../contrib/apr-util/include/private -I/usr/src/usr.bin/svn/lib/libsvn_subr/../../../../contrib/apr-util/include -I/usr/src/usr.bin/svn/lib/libsvn_subr/../../../../contrib/sqlite3 -g -std=gnu99 -Qunused-arguments -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-conversion -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses -c /usr/src/usr.bin/svn/lib/libsvn_subr/../../../../contrib/subversion/subversion/libsvn_subr/named_atomic.c -o named_atomic.o ExpandIntegerResult #0: 0x803433a10: i64,ch = AtomicCmpSwap 0x802d82438, 0x803432c10, 0x803432510, 0x803431310 [ORD=477] [ID=0] dbg:/usr/src/usr.bin/svn/lib/libsvn_subr/../../../../contrib/subversion/subversion/libsvn_subr/named_atomic.c:657 Do not know how to expand the result of this operator! UNREACHABLE executed at /usr/src/lib/clang/libllvmselectiondag/../../../contrib/llvm/lib/CodeGen/SelectionDAG/LegalizeIntegerTypes.cpp:1083! Stack dump: 0. Program arguments: /usr/obj/arm.arm/usr/src/tmp/usr/bin/cc -cc1 -triple armv4t--freebsd10.0-gnueabi -S -disable-free -main-file-name named_atomic.c -mrelocation-model static -mdisable-fp-elim -mconstructor-aliases -target-abi aapcs-linux -target-cpu arm7tdmi -msoft-float -mfloat-abi soft -target-feature +soft-float -target-feature +soft-float-abi -target-feature -neon -g -coverage-file /tmp/named_atomic-LvTbWX.s -resource-dir /usr/obj/arm.arm/usr/src/tmp/usr/bin/../lib/clang/3.3 -I /usr/src/usr.bin/svn/lib/libsvn_subr/../../../../contrib/subversion/subversion/include -I /usr/src/usr.bin/svn/lib/libsvn_subr/../../../../contrib/subversion/subversion -I /usr/src/usr.bin/svn/lib/libsvn_subr/../.. -I /usr/src/usr.bin/svn/lib/libsvn_subr/../libapr -I /usr/src/usr.bin/svn/lib/libsvn_subr/../../../../contrib/apr/include/arch/unix -I /usr/src/usr.bin/svn/lib/libsvn_subr/../../../../contrib/apr/include -I /usr/src/usr.bin/svn/lib/libsvn_subr/../libapr_util -I /usr/src/usr.bin/svn/lib/libsvn_subr/../../../../contrib/apr-util/include/private -I /usr/src/usr.bin/svn/lib/libsvn_subr/../../../../contrib/apr-util/include -I /usr/src/usr.bin/svn/lib/libsvn_subr/../../../../contrib/sqlite3 -isysroot /usr/obj/arm.arm/usr/src/tmp -O2 -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-conversion -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses -std=gnu99 -fno-dwarf-directory-asm -fdebug-compilation-dir /usr/obj/arm.arm/usr/src/usr.bin/svn/lib/libsvn_subr -ferror-limit 19 -fmessage-length 80 -mstackrealign -fno-signed-char -fobjc-runtime=gnustep -fobjc-default-synthesize-properties -fdiagnostics-show-option -fcolor-diagnostics -backend-option -vectorize-loops -o /tmp/named_atomic-LvTbWX.s -x c /usr/src/usr.bin/svn/lib/libsvn_subr/../../../../contrib/subversion/subversion/libsvn_subr/named_atomic.c 1. parser at end of file 2. Code generation 3. Running pass 'Function Pass Manager' on module '/usr/src/usr.bin/svn/lib/libsvn_subr/../../../../contrib/subversion/subversion/libsvn_subr/named_atomic.c'. 4. Running pass 'ARM Instruction Selection' on function '@svn_named_atomic__cmpxchg' cc: error: unable to execute command: Abort trap: 6 (core dumped) cc: error: clang frontend command failed due to signal (use -v to see invocation) FreeBSD clang version 3.3 (tags/RELEASE_33/final 183502) 20130610 Target: arm--freebsd10.0-gnueabi Thread model: posix cc: note: diagnostic msg: PLEASE submit a bug report to http://llvm.org/bugs/ and include the crash backtrace, preprocessed source, and associated run script. cc: note: diagnostic msg: Error generating preprocessed source(s). *** Error code 254 Stop. bmake[5]: stopped in /usr/src/usr.bin/svn/lib/libsvn_subr *** Error code 1 From owner-freebsd-arm@FreeBSD.ORG Thu Sep 19 13:00:59 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id F1B51D39 for ; Thu, 19 Sep 2013 13:00:59 +0000 (UTC) (envelope-from lists.br@gmail.com) Received: from mail-wi0-x22c.google.com (mail-wi0-x22c.google.com [IPv6:2a00:1450:400c:c05::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 8DC0A2C73 for ; Thu, 19 Sep 2013 13:00:59 +0000 (UTC) Received: by mail-wi0-f172.google.com with SMTP id hn9so5559352wib.11 for ; Thu, 19 Sep 2013 06:00:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=BQ9BLUaFDHcyUIdeXWJrrGYxCizTUFbx3Rwn6YHrkRU=; b=D8OWMIC0LRW096JIJu51XqR6Ltk4uYd7nnspxd1nGc0RgbYPIDHT2CsscnhqTexTeM 0UBdYdEA+Q+AX1WpeP46WU2hJAl9+KguZwmYk+sjCI51USa/p846CuNqXLSw1CxZDFRO +VH9CqiRC7JAUe3fIUxgwDdgKDFRQ5eLoyLIjfNioAPZl35+ksQTxOtvMYxtPv6iBvco THndsvlw3VLiiawkzouuwmX4pSJBJ2cmVm3vy7av5vEYQ9EKd8w+i7oCQPwTQ6a6TETE AKzXbBxQw2RsVNsGxM0gs4CZ4XjvPmXP+SWhRaiuEd22vjNEBd0FSN8KpHNbBuJFWYDE sMjg== MIME-Version: 1.0 X-Received: by 10.194.89.233 with SMTP id br9mr1312260wjb.15.1379595657909; Thu, 19 Sep 2013 06:00:57 -0700 (PDT) Received: by 10.216.75.140 with HTTP; Thu, 19 Sep 2013 06:00:57 -0700 (PDT) In-Reply-To: <935B7003-F750-42E7-9100-C27028B6A111@gmail.com> References: <935B7003-F750-42E7-9100-C27028B6A111@gmail.com> Date: Thu, 19 Sep 2013 10:00:57 -0300 Message-ID: Subject: Re: SPI device on Raspberry PI From: Luiz Otavio O Souza To: fabiodive Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: "freebsd-arm@FreeBSD.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Sep 2013 13:01:00 -0000 On 17 September 2013 19:00, fabiodive wrote: > Hello Luiz, > > I was able to use your patches on Raspberry PI, > I builded an image with crochet and this is my dmesg output: > > > [...] > > Now.. I see the GPIO device and iic as well but what about SPI? > Should I create the device or just use GPIO? > Any ideas? > > The devices you see for gpio and iic are used to control (or read and write data) from userland and actually there is no such support for SPI. I've plans to write an userland tool similar to i2c(8) for SPI together with some other pending work i've for SPI. But until it happens you need a kernel driver for the SPI device you want to use: spi0: mem 0x20204000-0x2020401f irq 62 on simplebus0 spibus0: on spi0 mx25l0: at cs 0 on spibus0 enc28j600: at cs 1 on spibus0 And the bindings also need to be described in the rpi dts file, i.e. in my case: spi0 { flash0 { compatible = "flash,mx25l"; spi-chipselect = <0>; }; enc28j600 { compatible = "ethernet,enc28j60"; spi-chipselect = <1>; }; }; Thanks for your feedback. Luiz From owner-freebsd-arm@FreeBSD.ORG Thu Sep 19 14:56:34 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id A2481212 for ; Thu, 19 Sep 2013 14:56:34 +0000 (UTC) (envelope-from rrs@lakerest.net) Received: from lakerest.net (lakerest.net [70.155.160.98]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 0450B23C4 for ; Thu, 19 Sep 2013 14:56:33 +0000 (UTC) Received: from [10.1.1.103] (bsd4.lakerest.net [70.155.160.102]) (authenticated bits=0) by lakerest.net (8.14.4/8.14.3) with ESMTP id r8JEuT1J053882 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Thu, 19 Sep 2013 10:56:32 -0400 (EDT) (envelope-from rrs@lakerest.net) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Apple Message framework v1283) Subject: Re: Trouble with a dream plug... From: Randall Stewart In-Reply-To: <3D3276E2-7436-4E98-A37D-1529C1752158@lakerest.net> Date: Thu, 19 Sep 2013 10:56:29 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <6ED6910A-C3C0-432A-B3FF-6F2D76EB6869@lakerest.net> References: <3D3276E2-7436-4E98-A37D-1529C1752158@lakerest.net> To: ARM X-Mailer: Apple Mail (2.1283) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Sep 2013 14:56:34 -0000 Ok So I figured it out ;-) Turns out there is a DREAMPLUG configuration.. which then gets the right fdt.. I did not realize we compile it into the kernel..=20 But I have noticed one issue at least with my dream plug.. The power management chip, consulted to see whats up and not, is defined as 0x1c in the mvreg.h. And yet in the spec its 0x18 for at least my model of the chip from marvel). Now another curious thing is that when you read the register, its 0 if its on and 1 if its disabled.=20 The code seems to do the opposite=85 i.e. look for a 1 if its enabled and 0 for not. I suspect this is due to the fact that 0x1c is the clock timing register and the 1's are were being mistaken for "on" when they were looking at the wrong register. It could be that the chip changed however, so I am ifdef'ing all my changes to be around the KIRKWOOD chip. I will supply a patch as soon as I make sure this all does not blow up when I bring it up ;-) R On Sep 19, 2013, at 8:24 AM, Randall Stewart wrote: > Hi all: >=20 > I am playing with a DreamPlug which has the marvell 88F6281 chip set > in it: >=20 > http://www.globalscaletechnologies.com/p-54-dreamplug-devkit.aspx >=20 > The version number of this seems to be 3. >=20 > When I first tried to bring it up following the wiki: > https://wiki.freebsd.org/FreeBSDMarvell >=20 > I had no joy, the system would boot up until it tried to find the = ethernet and die=85 >=20 > So with a bit of playing I figured out that the miiphy was incorrect, = it was trying > to use 8 and I found with a bit of poking that the two phys are on 0 = and 1 (There are > two Marvell Gig-E's on this critter). >=20 > Now after I got it to boot, I wanted to find a way to get the second = ethernet up. Linux > (which comes with it of course) finds both of them so why can't I? >=20 > So after digging some and learning about the flattened device tree, I = find that the layout of this in respect > to the ether-net is as follows (reported by a modified ofwdump.. I had = to make it so that=20 > it did not exit when it sees a next-prop return an error, evidently = this little arm just gives > you an error, not a 0 back when you hit the end of the properties). = Anyway here is my=20 > ethernet description: > ********************************* > Node 0x840: ethernet@72000 > #address-cells: > 00 00 00 01 > #size-cells: > 00 00 00 01 > model: > 56 32 00 > 'V2' > compatible: > 6d 72 76 6c 2c 67 65 00 > 'mrvl,ge' > reg: > 00 07 20 00 00 00 20 00 > ranges: =20 > 00 00 00 00 00 07 20 00 00 00 20 00 > local-mac-address: > 00 00 00 00 00 00 > interrupts: > 00 00 00 0c 00 00 00 0d 00 00 00 0e 00 00 00 0b 00 00 00 2e > interrupt-parent:=20 > 00 00 00 01 =20 > phy-handle: =20 > 00 00 00 02 > ------------Child of the E-net ------------ > Node 0x918: mdio@0 > #address-cells: > 00 00 00 01 > #size-cells: > 00 00 00 00 > compatible: > 6d 72 76 6c 2c 6d 64 69 6f 00 > 'mrvl,mdio' > ---------Child of the mdio ----------- > Node 0x95c: ethernet-phy@0 > reg: > 00 00 00 08 > phandle: > 00 00 00 02 > **************************** >=20 >> =46rom this you can see where the idea of the phy being at 8 is = coming from. Its sure > enough is in the ethernet-phy. Now I am *not* sure what an mdio is = supposed to do > for us, and even more strange is how does linux seem to be able to = bring up both ports > on this? >=20 > The spec's say that the first port is at 72000 - 73fff and the second = is at > 76000 - 77fff. And of course with no FDT description we won't see it. >=20 > Is our friend linux just assuming that its at those addresses? We end = up with > a list of IRQ's there as well 0xb, 0xc, 0xd, 0xe an 0x2e. Linux uses = 0xb for eth0 and 0xf > for eth1. >=20 > Anyone out there familiar with why I can't see the second network? Is = this a > bad fdt that came from the vendor? or do we need to just have driver = hacks in > that "assume" the second one is there? If so I am not sure how to deal = with the IRQ's > can we just allocate one? Linux seems fine with doing that unless = there is something > I am missing in my limited understanding of the FDT stuff. >=20 > Any pointers or hints would be appreciated. >=20 >=20 > R >=20 >=20 > ------------------------------ > Randall Stewart > 803-317-4952 (cell) >=20 > _______________________________________________ > 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" >=20 ------------------------------ Randall Stewart 803-317-4952 (cell) From owner-freebsd-arm@FreeBSD.ORG Thu Sep 19 15:13:46 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 0A3698C5 for ; Thu, 19 Sep 2013 15:13:46 +0000 (UTC) (envelope-from mattia.rossi.mailinglists@gmail.com) Received: from mail-ee0-x22f.google.com (mail-ee0-x22f.google.com [IPv6:2a00:1450:4013:c00::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 8813224E8 for ; Thu, 19 Sep 2013 15:13:45 +0000 (UTC) Received: by mail-ee0-f47.google.com with SMTP id d49so4197650eek.20 for ; Thu, 19 Sep 2013 08:13:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=Vks4FTcKFjZm0pj7fX1GFzXFG+25tXsIhaSkHrx2TVc=; b=kgjKy7NQEqnE5GAt76MbbvZVuFJJG5V5+PrxzT91cwP1QTjQ3eO70O1xlcd41PAt/k Y4n5MSk05tmG4d7IlwaTUnf1Xc65K+5T3A1x3l/LL+fUOJMVLzxU8VZtOTc6rHyIjmCJ 0kcobVUrUgSlExn84p0OxaF6DnLJeQPeZA4hCOjK1xzcBBtxfGWGxHpENXslsWYIx9jG X1i2Mj4bMyfW4G8TR8NBABR1/or37niFXEk5ifRthT9ZN6lRjxbbaAhUG7EfYRVzzgTK c+0szlhaVMcRUuH6pvhSMPALyyQJNlvYSdkkDIBG80yVSQ9ibd/u6fFUYDhgKjNAO6MN JXag== X-Received: by 10.14.224.198 with SMTP id x46mr2770512eep.53.1379603623863; Thu, 19 Sep 2013 08:13:43 -0700 (PDT) Received: from [192.168.0.108] (vpn.static.83-173-212-209.cybernet.ch. [83.173.212.209]) by mx.google.com with ESMTPSA id x47sm12003234eea.16.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 19 Sep 2013 08:13:43 -0700 (PDT) Message-ID: <523B14A6.8070209@gmail.com> Date: Thu, 19 Sep 2013 17:13:42 +0200 From: Mattia Rossi User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Randall Stewart Subject: Re: Trouble with a dream plug... References: <3D3276E2-7436-4E98-A37D-1529C1752158@lakerest.net> In-Reply-To: <3D3276E2-7436-4E98-A37D-1529C1752158@lakerest.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: ARM X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Sep 2013 15:13:46 -0000 Hi Randall, it's not on the FreeBSDMarvell wiki, but Ian (if I remember correctly) already added all the necessary tweaks to get FreeBSD on the DreamPlug. In fact, I'm running the most recent HEAD on it, compiled with Clang. Both ETH interfaces working, so far no trouble. He has also created the Kernel for the NAND-Version of the Dreamplug, which supposedly has an N after the Version number. I'm not too sure which one you have. But before getting old trying to fix the DB-* and SHEEVAPLUG Kernconfs and FDT's I'd suggest t compile using KERNCONF=DREAMPLUG-1001 Then I'd suggest to use a FAT partition on the internal SDcard of the dreamplug to host/store the kernel and an additional partiion (or more) for the world. If the FAT partition is your first partition on the SDcard it will be da0s1 so change the DREAMPLUG-1001 config file accordingly at the rootdevice option. I'd also suggest to put the world/root on a USB Stick to boot the first time, and use that instead of the nfs root. I usually tar and untar world on the stick using the -p option. On upgrades just remember to do a 'chflags -R noschg *', but I guess you'd know that. Remember to set the rc.conf and fstab files up properly. The device will be da1s1 (or da2s1 if you have an additional sdcard in the sdcard slot) Boot the dreamplug with the usb stick attached, then: in U-Boot stop autoboot, then type: set ipaddr set serverip usb start tftpboot 0x900000 /kernel.bin go 900000 It should boot, and the kernel should fail to find the root, so just type ufs:/da1s1 (or da2s1 if you have an additional sdcard in the sdcard slot) then go on booting. You should land in multiuser mode. Partition the internal disk into a small msdosfs partition (da0s1) and a larger (or multiple) root (da0s2) partition(s) (I use ufs) copy the kernel (tftp) into the msdosfs partition and the world onto the other partition(s). If you fixed the kernel config before, the kernel will look for the root file system on the right spot (da0s2). Next time you boot you just need to change the x_boot_cmd variable in u-boot to: fatload usb 0 0x900000 kernel.bin and the autoboot variable to go 900000 -> that's somewhat trickier and I can't remember how i did it... Ask again once you got there. From there on, you should be able to autoboot your dreamplug into FreeBSD Multiuser without hassle. Hope that helps, Mat Am 19.09.2013 14:24, schrieb Randall Stewart: > Hi all: > > I am playing with a DreamPlug which has the marvell 88F6281 chip set > in it: > > http://www.globalscaletechnologies.com/p-54-dreamplug-devkit.aspx > > The version number of this seems to be 3. > > When I first tried to bring it up following the wiki: > https://wiki.freebsd.org/FreeBSDMarvell > > I had no joy, the system would boot up until it tried to find the ethernet and die… > > So with a bit of playing I figured out that the miiphy was incorrect, it was trying > to use 8 and I found with a bit of poking that the two phys are on 0 and 1 (There are > two Marvell Gig-E's on this critter). > > Now after I got it to boot, I wanted to find a way to get the second ethernet up. Linux > (which comes with it of course) finds both of them so why can't I? > > So after digging some and learning about the flattened device tree, I find that the layout of this in respect > to the ether-net is as follows (reported by a modified ofwdump.. I had to make it so that > it did not exit when it sees a next-prop return an error, evidently this little arm just gives > you an error, not a 0 back when you hit the end of the properties). Anyway here is my > ethernet description: > ********************************* > Node 0x840: ethernet@72000 > #address-cells: > 00 00 00 01 > #size-cells: > 00 00 00 01 > model: > 56 32 00 > 'V2' > compatible: > 6d 72 76 6c 2c 67 65 00 > 'mrvl,ge' > reg: > 00 07 20 00 00 00 20 00 > ranges: > 00 00 00 00 00 07 20 00 00 00 20 00 > local-mac-address: > 00 00 00 00 00 00 > interrupts: > 00 00 00 0c 00 00 00 0d 00 00 00 0e 00 00 00 0b 00 00 00 2e > interrupt-parent: > 00 00 00 01 > phy-handle: > 00 00 00 02 > ------------Child of the E-net ------------ > Node 0x918: mdio@0 > #address-cells: > 00 00 00 01 > #size-cells: > 00 00 00 00 > compatible: > 6d 72 76 6c 2c 6d 64 69 6f 00 > 'mrvl,mdio' > ---------Child of the mdio ----------- > Node 0x95c: ethernet-phy@0 > reg: > 00 00 00 08 > phandle: > 00 00 00 02 > **************************** > > From this you can see where the idea of the phy being at 8 is coming from. Its sure > enough is in the ethernet-phy. Now I am *not* sure what an mdio is supposed to do > for us, and even more strange is how does linux seem to be able to bring up both ports > on this? > > The spec's say that the first port is at 72000 - 73fff and the second is at > 76000 - 77fff. And of course with no FDT description we won't see it. > > Is our friend linux just assuming that its at those addresses? We end up with > a list of IRQ's there as well 0xb, 0xc, 0xd, 0xe an 0x2e. Linux uses 0xb for eth0 and 0xf > for eth1. > > Anyone out there familiar with why I can't see the second network? Is this a > bad fdt that came from the vendor? or do we need to just have driver hacks in > that "assume" the second one is there? If so I am not sure how to deal with the IRQ's > can we just allocate one? Linux seems fine with doing that unless there is something > I am missing in my limited understanding of the FDT stuff. > > Any pointers or hints would be appreciated. > > > R > > > ------------------------------ > Randall Stewart > 803-317-4952 (cell) > > _______________________________________________ > freebsd-arm@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" From owner-freebsd-arm@FreeBSD.ORG Thu Sep 19 15:30:44 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 604A4E8 for ; Thu, 19 Sep 2013 15:30:44 +0000 (UTC) (envelope-from rrs@lakerest.net) Received: from lakerest.net (lakerest.net [70.155.160.98]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id A8FE42640 for ; Thu, 19 Sep 2013 15:30:43 +0000 (UTC) Received: from [10.1.1.103] (bsd4.lakerest.net [70.155.160.102]) (authenticated bits=0) by lakerest.net (8.14.4/8.14.3) with ESMTP id r8JFUeTl054268 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 19 Sep 2013 11:30:42 -0400 (EDT) (envelope-from rrs@lakerest.net) Subject: Re: Trouble with a dream plug... Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=windows-1252 From: Randall Stewart In-Reply-To: <523B14A6.8070209@gmail.com> Date: Thu, 19 Sep 2013 11:30:40 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <5487FF65-DEF3-4ABF-A72B-CAD0FD35659C@lakerest.net> References: <3D3276E2-7436-4E98-A37D-1529C1752158@lakerest.net> <523B14A6.8070209@gmail.com> To: Mattia Rossi X-Mailer: Apple Mail (2.1283) Cc: ARM X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Sep 2013 15:30:44 -0000 Mattia: in-line ;-) On Sep 19, 2013, at 11:13 AM, Mattia Rossi wrote: > Hi Randall, >=20 > it's not on the FreeBSDMarvell wiki, but Ian (if I remember correctly) = already added all the necessary tweaks to get FreeBSD on the DreamPlug. = In fact, I'm running the most recent HEAD on it, compiled with Clang. = Both ETH interfaces working, so far no trouble. > He has also created the Kernel for the NAND-Version of the Dreamplug, = which supposedly has an N after the Version number. I'm not too sure = which one you have. > But before getting old trying to fix the DB-* and SHEEVAPLUG Kernconfs = and FDT's I'd suggest t compile using >=20 > KERNCONF=3DDREAMPLUG-1001 Yep, I see that was my error.. I have it up now same .. with head and = clang ;-) I do think the checks in it for pm_is_disabled() and fdt_pm() is = incorrect. According the the marvell spec I have the power management register is at 18 not 1c. I = don't know if this is just my version of the chipset that has this or what. The spec I got is FS_88F6180_9x_6281_OpenSource and it seems correct when I do some debugging and have it give me both the 0x1c and 0x18 register. At least the values returned match the spec.. i.e. 0 =3D=3D device enabled, 1 =3D=3D device disabled = and the 1c register matches what I would guess is the correct settings for the clocks. I am wondering if this is just a code error ... >=20 > Then I'd suggest to use a FAT partition on the internal SDcard of the = dreamplug to host/store the kernel and an additional partiion (or more) = for the world. Yeah that was my next step after I play a bit with it and make sure I = can restore it. My initial boot of the right dream-plug configuration tried to go out to = da0s1, but I changed it locally back to NFS while I am testing. I will move shortly to = booting from flash ;-) >=20 > If the FAT partition is your first partition on the SDcard it will be = da0s1 so change the DREAMPLUG-1001 config file accordingly at the = rootdevice option. >=20 > I'd also suggest to put the world/root on a USB Stick to boot the = first time, and use that instead of the nfs root. > I usually tar and untar world on the stick using the -p option. > On upgrades just remember to do a 'chflags -R noschg *', but I guess = you'd know that. > Remember to set the rc.conf and fstab files up properly. The device = will be da1s1 (or da2s1 if you have an additional sdcard in the sdcard = slot) >=20 > Boot the dreamplug with the usb stick attached, then: >=20 > in U-Boot stop autoboot, then type: >=20 > set ipaddr > set serverip > usb start > tftpboot 0x900000 /kernel.bin > go 900000 >=20 > It should boot, and the kernel should fail to find the root, so just = type ufs:/da1s1 (or da2s1 if you have an additional sdcard in the sdcard = slot) >=20 > then go on booting. You should land in multiuser mode. Cool I will give it a whirl... >=20 > Partition the internal disk into a small msdosfs partition (da0s1) and = a larger (or multiple) root (da0s2) partition(s) (I use ufs) > copy the kernel (tftp) into the msdosfs partition and the world onto = the other partition(s). > If you fixed the kernel config before, the kernel will look for the = root file system on the right spot (da0s2). > Next time you boot you just need to change the x_boot_cmd variable in = u-boot to: >=20 > fatload usb 0 0x900000 kernel.bin >=20 > and the autoboot variable to go 900000 -> that's somewhat trickier and = I can't remember how i did it... > Ask again once you got there. Ok sounds good .. I will give it a go ;-) >=20 > =46rom there on, you should be able to autoboot your dreamplug into = FreeBSD Multiuser without hassle. Neat!! Do you know if the wifi has a driver for this puppy, or is it something = yet to be done ;-) I see the dts does not include a reference to it so I suppose its a "not = yet done" thing ;-D R >=20 > Hope that helps, >=20 > Mat >=20 > Am 19.09.2013 14:24, schrieb Randall Stewart: >> Hi all: >>=20 >> I am playing with a DreamPlug which has the marvell 88F6281 chip set >> in it: >>=20 >> http://www.globalscaletechnologies.com/p-54-dreamplug-devkit.aspx >>=20 >> The version number of this seems to be 3. >>=20 >> When I first tried to bring it up following the wiki: >> https://wiki.freebsd.org/FreeBSDMarvell >>=20 >> I had no joy, the system would boot up until it tried to find the = ethernet and die=85 >>=20 >> So with a bit of playing I figured out that the miiphy was incorrect, = it was trying >> to use 8 and I found with a bit of poking that the two phys are on 0 = and 1 (There are >> two Marvell Gig-E's on this critter). >>=20 >> Now after I got it to boot, I wanted to find a way to get the second = ethernet up. Linux >> (which comes with it of course) finds both of them so why can't I? >>=20 >> So after digging some and learning about the flattened device tree, I = find that the layout of this in respect >> to the ether-net is as follows (reported by a modified ofwdump.. I = had to make it so that >> it did not exit when it sees a next-prop return an error, evidently = this little arm just gives >> you an error, not a 0 back when you hit the end of the properties). = Anyway here is my >> ethernet description: >> ********************************* >> Node 0x840: ethernet@72000 >> #address-cells: >> 00 00 00 01 >> #size-cells: >> 00 00 00 01 >> model: >> 56 32 00 >> 'V2' >> compatible: >> 6d 72 76 6c 2c 67 65 00 >> 'mrvl,ge' >> reg: >> 00 07 20 00 00 00 20 00 >> ranges: >> 00 00 00 00 00 07 20 00 00 00 20 00 >> local-mac-address: >> 00 00 00 00 00 00 >> interrupts: >> 00 00 00 0c 00 00 00 0d 00 00 00 0e 00 00 00 0b 00 00 00 2e >> interrupt-parent: >> 00 00 00 01 >> phy-handle: >> 00 00 00 02 >> ------------Child of the E-net ------------ >> Node 0x918: mdio@0 >> #address-cells: >> 00 00 00 01 >> #size-cells: >> 00 00 00 00 >> compatible: >> 6d 72 76 6c 2c 6d 64 69 6f 00 >> 'mrvl,mdio' >> ---------Child of the mdio ----------- >> Node 0x95c: ethernet-phy@0 >> reg: >> 00 00 00 08 >> phandle: >> 00 00 00 02 >> **************************** >>=20 >> =46rom this you can see where the idea of the phy being at 8 is = coming from. Its sure >> enough is in the ethernet-phy. Now I am *not* sure what an mdio is = supposed to do >> for us, and even more strange is how does linux seem to be able to = bring up both ports >> on this? >>=20 >> The spec's say that the first port is at 72000 - 73fff and the second = is at >> 76000 - 77fff. And of course with no FDT description we won't see it. >>=20 >> Is our friend linux just assuming that its at those addresses? We end = up with >> a list of IRQ's there as well 0xb, 0xc, 0xd, 0xe an 0x2e. Linux uses = 0xb for eth0 and 0xf >> for eth1. >>=20 >> Anyone out there familiar with why I can't see the second network? Is = this a >> bad fdt that came from the vendor? or do we need to just have driver = hacks in >> that "assume" the second one is there? If so I am not sure how to = deal with the IRQ's >> can we just allocate one? Linux seems fine with doing that unless = there is something >> I am missing in my limited understanding of the FDT stuff. >>=20 >> Any pointers or hints would be appreciated. >>=20 >>=20 >> R >>=20 >>=20 >> ------------------------------ >> Randall Stewart >> 803-317-4952 (cell) >>=20 >> _______________________________________________ >> 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" >=20 ------------------------------ Randall Stewart 803-317-4952 (cell) From owner-freebsd-arm@FreeBSD.ORG Thu Sep 19 16:28:30 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 939A6ED2 for ; Thu, 19 Sep 2013 16:28:30 +0000 (UTC) (envelope-from mattia.rossi.mate@gmail.com) Received: from mail-ea0-x232.google.com (mail-ea0-x232.google.com [IPv6:2a00:1450:4013:c01::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 1CC7D2976 for ; Thu, 19 Sep 2013 16:28:29 +0000 (UTC) Received: by mail-ea0-f178.google.com with SMTP id a15so4316974eae.37 for ; Thu, 19 Sep 2013 09:28:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:reply-to:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=+4dGUbNqbT5eJNPDiDWTJjaVp1NYyHI4HovJIrLwfnY=; b=caczTHZtwvBUK5Pt8SaCZNHrkuio2FHtpSvapqLsOT7NLWUuh3mx7apJGkf6ecyuF+ OMmXO/GsP7RmEJSQRhBqsKO8P7VecO7eGjS4NP4LM1UFfin7m8WoHXYZZgJJPe1s7l6D bTFXB9d6tFPe25xKFOjVp0kJnCuoPw6Jvi5E/KRW1CmlnU+USvacytvXRAm4yRy9emk0 f+e9z3N7tWokwusLiwDykXjVOlMdVLpOPkh7OQDy43Wbr6cNu7WvM+AWtRhMqSBVsYUd WL37I1WOcjsUR0fJcHHXX5q7Zk1+fPlcRp4twWx6hhoFJdBtUPMoCgAizHDs9WojvTWy SRaA== X-Received: by 10.15.63.142 with SMTP id m14mr2075217eex.106.1379608108295; Thu, 19 Sep 2013 09:28:28 -0700 (PDT) Received: from [192.168.0.10] (46-126-92-160.dynamic.hispeed.ch. [46.126.92.160]) by mx.google.com with ESMTPSA id z12sm12551980eev.6.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 19 Sep 2013 09:28:27 -0700 (PDT) Message-ID: <523B2629.6080101@gmail.com> Date: Thu, 19 Sep 2013 18:28:25 +0200 From: Mattia Rossi User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Randall Stewart Subject: Re: Trouble with a dream plug... References: <3D3276E2-7436-4E98-A37D-1529C1752158@lakerest.net> <523B14A6.8070209@gmail.com> <5487FF65-DEF3-4ABF-A72B-CAD0FD35659C@lakerest.net> In-Reply-To: <5487FF65-DEF3-4ABF-A72B-CAD0FD35659C@lakerest.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: ARM X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: mattia.rossi.mate@gmail.com List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Sep 2013 16:28:30 -0000 I just top-post for simplicity: The WiFi and Bluetooth chips sit on a SDIO card. SDIO support is currently being hacked together as far as I'm aware (I'm not involved). About the WiFi driver itself, I recall some messages going on about it, and it seems that that driver needs to include some marvell specific SDIO magic and that it would be tricky to port from Linux. Mat On 19/09/13 17:30, Randall Stewart wrote: > Mattia: > > in-line ;-) > > On Sep 19, 2013, at 11:13 AM, Mattia Rossi wrote: > >> Hi Randall, >> >> it's not on the FreeBSDMarvell wiki, but Ian (if I remember correctly) already added all the necessary tweaks to get FreeBSD on the DreamPlug. In fact, I'm running the most recent HEAD on it, compiled with Clang. Both ETH interfaces working, so far no trouble. >> He has also created the Kernel for the NAND-Version of the Dreamplug, which supposedly has an N after the Version number. I'm not too sure which one you have. >> But before getting old trying to fix the DB-* and SHEEVAPLUG Kernconfs and FDT's I'd suggest t compile using >> >> KERNCONF=DREAMPLUG-1001 > Yep, I see that was my error.. I have it up now same .. with head and clang ;-) > > I do think the checks in it for pm_is_disabled() and fdt_pm() is incorrect. According the the > marvell spec I have the power management register is at 18 not 1c. I don't know > if this is just my version of the chipset that has this or what. > > The spec I got is FS_88F6180_9x_6281_OpenSource > and it seems correct when I do some debugging and have it give me > both the 0x1c and 0x18 register. At least the values returned > match the spec.. i.e. 0 == device enabled, 1 == device disabled and > the 1c register matches what I would guess is the correct settings for > the clocks. > > I am wondering if this is just a code error ... > > >> Then I'd suggest to use a FAT partition on the internal SDcard of the dreamplug to host/store the kernel and an additional partiion (or more) for the world. > Yeah that was my next step after I play a bit with it and make sure I can restore it. My > initial boot of the right dream-plug configuration tried to go out to da0s1, but I changed > it locally back to NFS while I am testing. I will move shortly to booting from flash ;-) > >> If the FAT partition is your first partition on the SDcard it will be da0s1 so change the DREAMPLUG-1001 config file accordingly at the rootdevice option. >> >> I'd also suggest to put the world/root on a USB Stick to boot the first time, and use that instead of the nfs root. >> I usually tar and untar world on the stick using the -p option. >> On upgrades just remember to do a 'chflags -R noschg *', but I guess you'd know that. >> Remember to set the rc.conf and fstab files up properly. The device will be da1s1 (or da2s1 if you have an additional sdcard in the sdcard slot) >> >> Boot the dreamplug with the usb stick attached, then: >> >> in U-Boot stop autoboot, then type: >> >> set ipaddr >> set serverip >> usb start >> tftpboot 0x900000 /kernel.bin >> go 900000 >> >> It should boot, and the kernel should fail to find the root, so just type ufs:/da1s1 (or da2s1 if you have an additional sdcard in the sdcard slot) >> >> then go on booting. You should land in multiuser mode. > Cool I will give it a whirl... > >> Partition the internal disk into a small msdosfs partition (da0s1) and a larger (or multiple) root (da0s2) partition(s) (I use ufs) >> copy the kernel (tftp) into the msdosfs partition and the world onto the other partition(s). >> If you fixed the kernel config before, the kernel will look for the root file system on the right spot (da0s2). >> Next time you boot you just need to change the x_boot_cmd variable in u-boot to: >> >> fatload usb 0 0x900000 kernel.bin >> >> and the autoboot variable to go 900000 -> that's somewhat trickier and I can't remember how i did it... >> Ask again once you got there. > Ok sounds good .. I will give it a go ;-) > >> From there on, you should be able to autoboot your dreamplug into FreeBSD Multiuser without hassle. > Neat!! > > Do you know if the wifi has a driver for this puppy, or is it something yet to be done ;-) > > I see the dts does not include a reference to it so I suppose its a "not yet done" thing ;-D > > R > >> Hope that helps, >> >> Mat >> >> Am 19.09.2013 14:24, schrieb Randall Stewart: >>> Hi all: >>> >>> I am playing with a DreamPlug which has the marvell 88F6281 chip set >>> in it: >>> >>> http://www.globalscaletechnologies.com/p-54-dreamplug-devkit.aspx >>> >>> The version number of this seems to be 3. >>> >>> When I first tried to bring it up following the wiki: >>> https://wiki.freebsd.org/FreeBSDMarvell >>> >>> I had no joy, the system would boot up until it tried to find the ethernet and die… >>> >>> So with a bit of playing I figured out that the miiphy was incorrect, it was trying >>> to use 8 and I found with a bit of poking that the two phys are on 0 and 1 (There are >>> two Marvell Gig-E's on this critter). >>> >>> Now after I got it to boot, I wanted to find a way to get the second ethernet up. Linux >>> (which comes with it of course) finds both of them so why can't I? >>> >>> So after digging some and learning about the flattened device tree, I find that the layout of this in respect >>> to the ether-net is as follows (reported by a modified ofwdump.. I had to make it so that >>> it did not exit when it sees a next-prop return an error, evidently this little arm just gives >>> you an error, not a 0 back when you hit the end of the properties). Anyway here is my >>> ethernet description: >>> ********************************* >>> Node 0x840: ethernet@72000 >>> #address-cells: >>> 00 00 00 01 >>> #size-cells: >>> 00 00 00 01 >>> model: >>> 56 32 00 >>> 'V2' >>> compatible: >>> 6d 72 76 6c 2c 67 65 00 >>> 'mrvl,ge' >>> reg: >>> 00 07 20 00 00 00 20 00 >>> ranges: >>> 00 00 00 00 00 07 20 00 00 00 20 00 >>> local-mac-address: >>> 00 00 00 00 00 00 >>> interrupts: >>> 00 00 00 0c 00 00 00 0d 00 00 00 0e 00 00 00 0b 00 00 00 2e >>> interrupt-parent: >>> 00 00 00 01 >>> phy-handle: >>> 00 00 00 02 >>> ------------Child of the E-net ------------ >>> Node 0x918: mdio@0 >>> #address-cells: >>> 00 00 00 01 >>> #size-cells: >>> 00 00 00 00 >>> compatible: >>> 6d 72 76 6c 2c 6d 64 69 6f 00 >>> 'mrvl,mdio' >>> ---------Child of the mdio ----------- >>> Node 0x95c: ethernet-phy@0 >>> reg: >>> 00 00 00 08 >>> phandle: >>> 00 00 00 02 >>> **************************** >>> >>> From this you can see where the idea of the phy being at 8 is coming from. Its sure >>> enough is in the ethernet-phy. Now I am *not* sure what an mdio is supposed to do >>> for us, and even more strange is how does linux seem to be able to bring up both ports >>> on this? >>> >>> The spec's say that the first port is at 72000 - 73fff and the second is at >>> 76000 - 77fff. And of course with no FDT description we won't see it. >>> >>> Is our friend linux just assuming that its at those addresses? We end up with >>> a list of IRQ's there as well 0xb, 0xc, 0xd, 0xe an 0x2e. Linux uses 0xb for eth0 and 0xf >>> for eth1. >>> >>> Anyone out there familiar with why I can't see the second network? Is this a >>> bad fdt that came from the vendor? or do we need to just have driver hacks in >>> that "assume" the second one is there? If so I am not sure how to deal with the IRQ's >>> can we just allocate one? Linux seems fine with doing that unless there is something >>> I am missing in my limited understanding of the FDT stuff. >>> >>> Any pointers or hints would be appreciated. >>> >>> >>> R >>> >>> >>> ------------------------------ >>> Randall Stewart >>> 803-317-4952 (cell) >>> >>> _______________________________________________ >>> 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" > ------------------------------ > Randall Stewart > 803-317-4952 (cell) > From owner-freebsd-arm@FreeBSD.ORG Thu Sep 19 16:48:04 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id AB9E37CD for ; Thu, 19 Sep 2013 16:48:04 +0000 (UTC) (envelope-from rrs@lakerest.net) Received: from lakerest.net (lakerest.net [70.155.160.98]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 2F2042A80 for ; Thu, 19 Sep 2013 16:48:03 +0000 (UTC) Received: from [10.1.1.103] (bsd4.lakerest.net [70.155.160.102]) (authenticated bits=0) by lakerest.net (8.14.4/8.14.3) with ESMTP id r8JGm2I4055169 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Thu, 19 Sep 2013 12:48:02 -0400 (EDT) (envelope-from rrs@lakerest.net) From: Randall Stewart Content-Type: multipart/mixed; boundary="Apple-Mail=_176D3252-AA19-42AA-83F9-2E5C693C5801" Subject: dream plug patch to get right power management Date: Thu, 19 Sep 2013 12:48:02 -0400 Message-Id: To: ARM Mime-Version: 1.0 (Apple Message framework v1283) X-Mailer: Apple Mail (2.1283) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Sep 2013 16:48:04 -0000 --Apple-Mail=_176D3252-AA19-42AA-83F9-2E5C693C5801 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii All: Here is the patch I am considering putting in I guess after the freeze. This corrects it so the kirkwood chip uses the right register for the power management lookups. Comments? R --Apple-Mail=_176D3252-AA19-42AA-83F9-2E5C693C5801 Content-Disposition: attachment; filename=arm_patch.txt Content-Type: text/plain; x-unix-mode=0644; name="arm_patch.txt" Content-Transfer-Encoding: 7bit Index: arm/mv/common.c =================================================================== --- arm/mv/common.c (revision 255614) +++ arm/mv/common.c (working copy) @@ -153,8 +153,11 @@ struct fdt_pm_mask_entry fdt_pm_mask_table[] = { static __inline int pm_is_disabled(uint32_t mask) { - +#if defined(SOC_MV_KIRKWOOD) + return (soc_power_ctrl_get(mask) == mask); +#else return (soc_power_ctrl_get(mask) == mask ? 0 : 1); +#endif } /* @@ -221,7 +224,16 @@ fdt_pm(phandle_t node) continue; compat = fdt_is_compatible(node, fdt_pm_mask_table[i].compat); - +#if defined(SOC_MV_KIRKWOOD) + if (compat && (cpu_pm_ctrl & fdt_pm_mask_table[i].mask)) { + dev_mask |= (1 << i); + ena = 0; + break; + } else if (compat) { + dev_mask |= (1 << i); + break; + } +#else if (compat && (~cpu_pm_ctrl & fdt_pm_mask_table[i].mask)) { dev_mask |= (1 << i); ena = 0; @@ -230,6 +242,7 @@ fdt_pm(phandle_t node) dev_mask |= (1 << i); break; } +#endif } return (ena); Index: arm/mv/mvreg.h =================================================================== --- arm/mv/mvreg.h (revision 255614) +++ arm/mv/mvreg.h (working copy) @@ -142,7 +142,11 @@ /* * Power Control */ +#if defined(SOC_MV_KIRKWOOD) +#define CPU_PM_CTRL 0x18 +#else #define CPU_PM_CTRL 0x1C +#endif #define CPU_PM_CTRL_NONE 0 #define CPU_PM_CTRL_ALL ~0x0 Index: dev/cesa/cesa.c =================================================================== --- dev/cesa/cesa.c (revision 255614) +++ dev/cesa/cesa.c (working copy) @@ -997,11 +997,17 @@ cesa_attach(device_t dev) sc->sc_dev = dev; /* Check if CESA peripheral device has power turned on */ +#if defined(SOC_MV_KIRKWOOD) + if (soc_power_ctrl_get(CPU_PM_CTRL_CRYPTO) == CPU_PM_CTRL_CRYPTO) { + device_printf(dev, "not powered on\n"); + return (ENXIO); + } +#else if (soc_power_ctrl_get(CPU_PM_CTRL_CRYPTO) != CPU_PM_CTRL_CRYPTO) { device_printf(dev, "not powered on\n"); return (ENXIO); } - +#endif soc_id(&d, &r); switch (d) { --Apple-Mail=_176D3252-AA19-42AA-83F9-2E5C693C5801 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii ------------------------------ Randall Stewart 803-317-4952 (cell) --Apple-Mail=_176D3252-AA19-42AA-83F9-2E5C693C5801-- From owner-freebsd-arm@FreeBSD.ORG Thu Sep 19 20:41:23 2013 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 3923BD81 for ; Thu, 19 Sep 2013 20:41:23 +0000 (UTC) (envelope-from torfinn.ingolfsen@getmail.no) Received: from galore.getmail.no (galore.getmail.no [84.210.184.6]) by mx1.freebsd.org (Postfix) with ESMTP id B231D28B0 for ; Thu, 19 Sep 2013 20:41:22 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by galore.getmail.no (Postfix) with ESMTP id 69ED6146707 for ; Thu, 19 Sep 2013 22:41:09 +0200 (CEST) X-Spam-Flag: NO X-Spam-Score: -2.94 X-Spam-Level: X-Spam-Status: No, score=-2.94 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_FB_WORD2_END_DOLLAR=0.01, T_KHOP_THREADED=-0.01, T_NICE_REPLY_A=0.01, T_TVD_SUBJ_NUM_OBFU=0.01, T_TVD_SUBJ_NUM_OBFU2=0.01, T_TVD_SUBJ_NUM_OBFU3=0.01, T_UNKNOWN_ORIGIN=0.01, T_UPPERCASE_URI=0.01] autolearn=ham Authentication-Results: galore.get.c.bitbit.net (amavisd-new); dkim=pass (1024-bit key) header.d=getmail.no Received: from galore.getmail.no ([127.0.0.1]) by localhost (galore.get.c.bitbit.net [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id Fj6aDUjhLTMV for ; Thu, 19 Sep 2013 22:41:09 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by galore.getmail.no (Postfix) with ESMTP id F1B8414672A for ; Thu, 19 Sep 2013 22:41:08 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.7.1 galore.getmail.no F1B8414672A DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=getmail.no; s=8A9C8B4C-D727-11E2-8095-B6466E6B3FA2; t=1379623269; bh=s7uDppTPvjDNqkXGzltYxyIc2EWjm/oq7UUUj5SEztU=; h=Date:From:To:Subject:Message-Id:Mime-Version:Content-Type: Content-Transfer-Encoding; b=U+xy/omucnWu/fJXd2UQwq/Ea+/pic6L/AOjOJ7me4rXUmbt+R90QqhYFiXrcb0dY wJZsaBFEpGGgMvEYoqYNMNf12JNsSVrH1uSThxmaUbiYR54QH7ImKt7TRgt+FxaFCv t3sFrQEAtznCb57117kLtrqM8YBDvsnqKxh512OU= X-Virus-Scanned: amavisd-new at Received: from galore.getmail.no ([127.0.0.1]) by localhost (galore.get.c.bitbit.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id g12tuH4OGRqf for ; Thu, 19 Sep 2013 22:41:08 +0200 (CEST) Received: from kg-core1.kg4.no (cm-84.215.180.206.getinternet.no [84.215.180.206]) by galore.getmail.no (Postfix) with ESMTPSA id CAE86146707 for ; Thu, 19 Sep 2013 22:41:08 +0200 (CEST) Date: Thu, 19 Sep 2013 22:41:08 +0200 From: Torfinn Ingolfsen To: freebsd-arm@FreeBSD.org Subject: Re: stm32flash under FreeBSD? Message-Id: <20130919224108.6bfa2926fcbeee3aa040877f@getmail.no> In-Reply-To: <1379548973.1197.76.camel@revolution.hippie.lan> References: <20130918101235.e1737d4bd839f71ebf554803@getmail.no> <1379511626.1197.69.camel@revolution.hippie.lan> <20130918215217.24905fd7f91523a0b70170b5@getmail.no> <1379548973.1197.76.camel@revolution.hippie.lan> X-Mailer: Sylpheed 3.3.0 (GTK+ 2.24.19; 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.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Sep 2013 20:41:23 -0000 On Wed, 18 Sep 2013 18:02:53 -0600 Ian Lepore wrote: > It looks to me like it's complaining about not finding libc's nls files > (which I would think would be in /usr/local/share), as if a required Are you sure about that? Isn't libc part of base? Anyway, both /usr/local/share/nls and /usr/share/nls exist (with subdirectories). But the "libc.cat" files only exist under /usr/share/nls: tingo@kg-core1$ find /usr/share/nls -name libc.cat -print /usr/share/nls/sk_SK.ISO8859-2/libc.cat /usr/share/nls/fr_FR.ISO8859-1/libc.cat /usr/share/nls/be_BY.UTF-8/libc.cat /usr/share/nls/zh_CN.GB2312/libc.cat /usr/share/nls/es_ES.ISO8859-1/libc.cat /usr/share/nls/pl_PL.ISO8859-2/libc.cat /usr/share/nls/ja_JP.eucJP/libc.cat /usr/share/nls/it_IT.ISO8859-15/libc.cat /usr/share/nls/ko_KR.eucKR/libc.cat /usr/share/nls/ca_ES.ISO8859-1/libc.cat /usr/share/nls/el_GR.ISO8859-7/libc.cat /usr/share/nls/de_DE.ISO8859-1/libc.cat /usr/share/nls/ko_KR.UTF-8/libc.cat /usr/share/nls/zh_CN.GB18030/libc.cat /usr/share/nls/fi_FI.ISO8859-1/libc.cat /usr/share/nls/no_NO.ISO8859-1/libc.cat /usr/share/nls/pt_BR.ISO8859-1/libc.cat /usr/share/nls/nl_NL.ISO8859-1/libc.cat /usr/share/nls/ja_JP.UTF-8/libc.cat /usr/share/nls/sv_SE.ISO8859-1/libc.cat /usr/share/nls/zh_CN.UTF-8/libc.cat /usr/share/nls/hu_HU.ISO8859-2/libc.cat /usr/share/nls/uk_UA.UTF-8/libc.cat /usr/share/nls/ru_RU.KOI8-R/libc.cat /usr/share/nls/mn_MN.UTF-8/libc.cat tingo@kg-core1$ find /usr/local/share/nls -name libc.cat -print But interestingly enough, there isn't a libc.cat file in /usr/share/nls/C. I don't know why. FWIW, LANG is set: tingo@kg-core1$ echo $LANG en_US.ISO8859-1 -- Torfinn Ingolfsen From owner-freebsd-arm@FreeBSD.ORG Thu Sep 19 20:50:39 2013 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 12464E8D for ; Thu, 19 Sep 2013 20:50:39 +0000 (UTC) (envelope-from torfinn.ingolfsen@getmail.no) Received: from bouvier.getmail.no (bouvier.getmail.no [84.210.184.8]) by mx1.freebsd.org (Postfix) with ESMTP id B737328F6 for ; Thu, 19 Sep 2013 20:50:38 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by bouvier.getmail.no (Postfix) with ESMTP id F0FB542447 for ; Thu, 19 Sep 2013 22:44:24 +0200 (CEST) X-Spam-Flag: NO X-Spam-Score: -2.96 X-Spam-Level: X-Spam-Status: No, score=-2.96 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_TVD_SUBJ_NUM_OBFU=0.01, T_TVD_SUBJ_NUM_OBFU2=0.01, T_TVD_SUBJ_NUM_OBFU3=0.01, T_UNKNOWN_ORIGIN=0.01] autolearn=ham Authentication-Results: bouvier.get.c.bitbit.net (amavisd-new); dkim=pass (1024-bit key) header.d=getmail.no Received: from bouvier.getmail.no ([127.0.0.1]) by localhost (bouvier.get.c.bitbit.net [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id rKNVVuedgM9X for ; Thu, 19 Sep 2013 22:44:24 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by bouvier.getmail.no (Postfix) with ESMTP id 959A6424E5 for ; Thu, 19 Sep 2013 22:44:24 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.7.1 bouvier.getmail.no 959A6424E5 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=getmail.no; s=8A9C8B4C-D727-11E2-8095-B6466E6B3FA2; t=1379623464; bh=M7nR547E+Z8OoAhuU8VLXr9fY3GSyy3ank57fUBF/sE=; h=Date:From:To:Subject:Message-Id:Mime-Version:Content-Type: Content-Transfer-Encoding; b=0toNjLeJ8vR6MN0TBrU74182qTHz+/QAUznxV6a+sDo673vG2roqZzrH91OlMUjDh PvsgBte5uzpoKD5W3grj+Ggkrc3m3G7apr0LQm26uyfNPe+N9yVnXhafvEVYXHviiz XiinV4486qDRmEMlbti4szcq1L909jDsAjyKcvD8= X-Virus-Scanned: amavisd-new at Received: from bouvier.getmail.no ([127.0.0.1]) by localhost (bouvier.get.c.bitbit.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id L4_z069_h5rt for ; Thu, 19 Sep 2013 22:44:24 +0200 (CEST) Received: from kg-core1.kg4.no (cm-84.215.180.206.getinternet.no [84.215.180.206]) by bouvier.getmail.no (Postfix) with ESMTPSA id 6089142447 for ; Thu, 19 Sep 2013 22:44:24 +0200 (CEST) Date: Thu, 19 Sep 2013 22:44:24 +0200 From: Torfinn Ingolfsen To: freebsd-arm@FreeBSD.org Subject: Re: stm32flash under FreeBSD? Message-Id: <20130919224424.d3f1a8ae8048da982ca3863b@getmail.no> In-Reply-To: <20130919110656.5F9E197257B@macavity.inf.ed.ac.uk> References: <20130919110656.5F9E197257B@macavity.inf.ed.ac.uk> X-Mailer: Sylpheed 3.3.0 (GTK+ 2.24.19; 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.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Sep 2013 20:50:39 -0000 On Thu, 19 Sep 2013 12:06:56 +0100 (BST) Richard Tobin wrote: > > Then it mangles the error reporting to make it > > look like the tty device was the thing not found. > > It appears to call perror(device) if serial_setup() returns an error, > even though that can fail without setting errno. To me (but I am no expert) it looks like it never reaches serial_setup(), it fails after serrial_open(). -- Torfinn Ingolfsen From owner-freebsd-arm@FreeBSD.ORG Thu Sep 19 21:29:18 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 6BB9996E for ; Thu, 19 Sep 2013 21:29:18 +0000 (UTC) (envelope-from richard@inf.ed.ac.uk) Received: from treacle.ucs.ed.ac.uk (treacle.ucs.ed.ac.uk [129.215.16.102]) by mx1.freebsd.org (Postfix) with ESMTP id 074632AF5 for ; Thu, 19 Sep 2013 21:29:17 +0000 (UTC) Received: from crunchie.inf.ed.ac.uk (crunchie.inf.ed.ac.uk [129.215.33.180]) by treacle.ucs.ed.ac.uk (8.13.8/8.13.4) with ESMTP id r8JLT0po008691; Thu, 19 Sep 2013 22:29:00 +0100 (BST) Received: from macavity.inf.ed.ac.uk (macavity.inf.ed.ac.uk [129.215.197.221]) by crunchie.inf.ed.ac.uk (8.14.4/8.14.4) with ESMTP id r8JLSxKg025404; Thu, 19 Sep 2013 22:28:59 +0100 Received: by macavity.inf.ed.ac.uk (Postfix, from userid 26013) id 5A46A97324E; Thu, 19 Sep 2013 22:29:00 +0100 (BST) From: Richard Tobin Subject: Re: stm32flash under FreeBSD? To: Torfinn Ingolfsen , freebsd-arm@freebsd.org In-Reply-To: Torfinn Ingolfsen's message of Thu, 19 Sep 2013 22:44:24 +0200 X-Mailer: Ream 5.1.51-richard-mac Message-Id: <20130919212900.5A46A97324E@macavity.inf.ed.ac.uk> Date: Thu, 19 Sep 2013 22:29:00 +0100 (BST) X-Edinburgh-Scanned: at treacle.ucs.ed.ac.uk with MIMEDefang 2.60, Sophie, Sophos Anti-Virus, Clam AntiVirus Content-Type: text/plain MIME-Version: 1.0 Content-Disposition: inline X-Scanned-By: MIMEDefang 2.60 on 129.215.16.102 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Sep 2013 21:29:18 -0000 > To me (but I am no expert) Nor me, but... > it looks like it never reaches > serial_setup(), it fails after serrial_open(). The log shows open, fcntl, tcgettatr, tcgettatr, tcflush, tcsetattr, tcgettatr. The NLS stuff is inside perror(). serial_open() does open, fcntl, tcgettatr, tcgettatr. serial_setup() does tcflush, tcsetattr, tcgettatr, and then fails if the tcgettatr doesn't match the tcsetattr. Presumably that's what's happening. I would put some debugging printf()s in to see what the settings returned by the tcgettattr in serial_setup() are. -- Richard -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. From owner-freebsd-arm@FreeBSD.ORG Thu Sep 19 22:36:12 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 65907705 for ; Thu, 19 Sep 2013 22:36:12 +0000 (UTC) (envelope-from andrew@fubar.geek.nz) Received: from nibbler.fubar.geek.nz (nibbler.fubar.geek.nz [199.48.134.198]) by mx1.freebsd.org (Postfix) with ESMTP id 469D52E0F for ; Thu, 19 Sep 2013 22:36:11 +0000 (UTC) Received: from bender.Home (97e5e46b.skybroadband.com [151.229.228.107]) by nibbler.fubar.geek.nz (Postfix) with ESMTPSA id 5A3895E2FD; Thu, 19 Sep 2013 22:36:10 +0000 (UTC) Date: Thu, 19 Sep 2013 23:36:01 +0100 From: Andrew Turner To: "Ronald Klop" Subject: Re: svn on armv5 with clang? (Fwd: svn commit: r254539 - head/usr.bin) Message-ID: <20130919233601.27bce4aa@bender.Home> In-Reply-To: References: <201308191744.r7JHiJ00063824@svn.freebsd.org> <20130917190215.7093f261@bender.Home> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Sep 2013 22:36:12 -0000 On Thu, 19 Sep 2013 14:57:25 +0200 "Ronald Klop" wrote: > On Tue, 17 Sep 2013 20:02:15 +0200, Andrew Turner > wrote: > > > On Tue, 17 Sep 2013 16:13:22 +0200 > > "Ronald Klop" wrote: > > > >> Hi, > >> > >> I am reading up on commits and found this one. Is ARMv5 capable of > >> building the in-tree svn also? > >> > > It is unlikely, I don't think we provide the required atomic > > functions for ARMv5. On armv6 clang provides them, however I don't > > thing it knows how to set up ARM_RAS_START. Without this we have to > > implement more of the __sync_* functions for svn to work on ARMv5. > > I don't know of any plans to add them. > > > > Andrew > > > > I just tried it and you are right. For some mailinglist documentation > I append the error here. > Is this something for FreeBSD to add or for clang/llvm folks? Or a > joint effort? It is something FreeBSD needs to add to sys/arm/arm/stdatomic.c. If anyone feels like working on it I would suggest they split out the armv6 version of the functions into a separate file as it is rather difficult to follow. Andrew From owner-freebsd-arm@FreeBSD.ORG Fri Sep 20 02:11:13 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 720E6220 for ; Fri, 20 Sep 2013 02:11:13 +0000 (UTC) (envelope-from tim@kientzle.com) Received: from monday.kientzle.com (99-115-135-74.uvs.sntcca.sbcglobal.net [99.115.135.74]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 503992661 for ; Fri, 20 Sep 2013 02:11:12 +0000 (UTC) Received: (from root@localhost) by monday.kientzle.com (8.14.4/8.14.4) id r8K2B5NK091646; Fri, 20 Sep 2013 02:11:05 GMT (envelope-from tim@kientzle.com) Received: from [192.168.2.123] (CiscoE3000 [192.168.1.65]) by kientzle.com with SMTP id x8pd4d8m2ipkg9kx69dtisnkni; Fri, 20 Sep 2013 02:11:05 +0000 (UTC) (envelope-from tim@kientzle.com) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Subject: Re: Trouble with a dream plug... From: Tim Kientzle In-Reply-To: <6ED6910A-C3C0-432A-B3FF-6F2D76EB6869@lakerest.net> Date: Thu, 19 Sep 2013 19:11:05 -0700 Content-Transfer-Encoding: 7bit Message-Id: <28AD84E4-50BC-4A69-8274-B2F4AAD53365@kientzle.com> References: <3D3276E2-7436-4E98-A37D-1529C1752158@lakerest.net> <6ED6910A-C3C0-432A-B3FF-6F2D76EB6869@lakerest.net> To: Randall Stewart X-Mailer: Apple Mail (2.1508) Cc: ARM X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Sep 2013 02:11:13 -0000 On Sep 19, 2013, at 7:56 AM, Randall Stewart wrote: > Ok > > So I figured it out ;-) > > Turns out there is a DREAMPLUG configuration.. which then gets > the right fdt.. I did not realize we compile it into the kernel.. On BeagleBone and RPi, an earlier boot loader loads the appropriate FDT into a known location in memory and ubldr(8) then passes that FDT to the kernel. Most of our ARM systems are still compiling the FDT into the kernel. Tim From owner-freebsd-arm@FreeBSD.ORG Fri Sep 20 10:32:10 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id DE89E8D1; Fri, 20 Sep 2013 10:32:10 +0000 (UTC) (envelope-from ronald-freebsd8@klop.yi.org) Received: from cpsmtpb-ews07.kpnxchange.com (cpsmtpb-ews07.kpnxchange.com [213.75.39.10]) by mx1.freebsd.org (Postfix) with ESMTP id 53D8C2D61; Fri, 20 Sep 2013 10:32:09 +0000 (UTC) Received: from cpsps-ews05.kpnxchange.com ([10.94.84.172]) by cpsmtpb-ews07.kpnxchange.com with Microsoft SMTPSVC(7.5.7601.17514); Fri, 20 Sep 2013 12:30:59 +0200 Received: from CPSMTPM-TLF101.kpnxchange.com ([195.121.3.4]) by cpsps-ews05.kpnxchange.com with Microsoft SMTPSVC(7.5.7601.17514); Fri, 20 Sep 2013 12:30:59 +0200 Received: from sjakie.klop.ws ([212.182.167.131]) by CPSMTPM-TLF101.kpnxchange.com with Microsoft SMTPSVC(7.5.7601.17514); Fri, 20 Sep 2013 12:30:58 +0200 Received: from 212-182-167-131.ip.telfort.nl (localhost [127.0.0.1]) by sjakie.klop.ws (Postfix) with ESMTP id B416FB2D3; Fri, 20 Sep 2013 12:30:58 +0200 (CEST) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes To: freebsd-fs@freebsd.org, freebsd-arm@freebsd.org Date: Fri, 20 Sep 2013 12:30:58 +0200 Subject: nandfs panic (bmap_truncate_mapping) MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Ronald Klop" Message-ID: User-Agent: Opera Mail/12.16 (FreeBSD) X-OriginalArrivalTime: 20 Sep 2013 10:30:59.0097 (UTC) FILETIME=[7F2E4090:01CEB5EC] X-RcptDomain: freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Sep 2013 10:32:10 -0000 Hi, I am using FreeBSD 10-CURRENT of 15 september on a SHEEVAPLUG ARMv5 machine. I did these steps: newfs_nandfs /dev/gnand0s.root mount -t nandfs /dev/gnand0s.root /mnt cd /; tar cf - / | tar -C /mnt -x -f - I did ctrl-c because I found it was tar-ing /mnt into /mnt/mnt. rm -r /mnt/mnt/* tar --one-file-system -c -f - / | tar -C /mnt -x -f - That gave the panic below. What information can I provide to solve this? Ronald. root@sh10:/ # panic: bmap_truncate_mapping: error 28 when truncate at level 0 KDB: enter: panic [ thread pid 755 tid 100066 ] Stopped at kdb_enter+0x4c: ldrb r15, [r15, r15, ror r15]! db> bt Tracing pid 755 tid 100066 td 0xc4e6e640 db_trace_self() at db_trace_self pc = 0xc0bb8b48 lr = 0xc093260c (db_hex2dec+0x494) sp = 0xde03a6b0 fp = 0xde03a6c8 r10 = 0xc0c99330 db_hex2dec() at db_hex2dec+0x494 pc = 0xc093260c lr = 0xc0931fc0 (db_command_loop+0x2f4) sp = 0xde03a6d0 fp = 0xde03a770 r4 = 0x00000000 r5 = 0x00000000 r6 = 0xc0c2d91e db_command_loop() at db_command_loop+0x2f4 pc = 0xc0931fc0 lr = 0xc0931d1c (db_command_loop+0x50) sp = 0xde03a778 fp = 0xde03a788 r4 = 0xc0c0143d r5 = 0xc0c1767f r6 = 0xc0ce74dc r7 = 0xde03a958 r8 = 0xc4e6e640 r9 = 0xc0cdca94 r10 = 0xc0c995a0 db_command_loop() at db_command_loop+0x50 pc = 0xc0931d1c lr = 0xc093466c (X_db_symbol_values+0x254) sp = 0xde03a790 fp = 0xde03a8b0 r4 = 0x00000000 r5 = 0xde03a798 r6 = 0xc0cdcac0 X_db_symbol_values() at X_db_symbol_values+0x254 pc = 0xc093466c lr = 0xc0a84b30 (kdb_trap+0xd4) sp = 0xde03a8b8 fp = 0xde03a8d8 r4 = 0x00000000 r5 = 0x00000001 r6 = 0xc0cdcac0 r7 = 0xde03a958 kdb_trap() at kdb_trap+0xd4 pc = 0xc0a84b30 lr = 0xc0bc9458 (undefinedinstruction+0x1fc) sp = 0xde03a8e0 fp = 0xde03a950 r4 = 0x00000000 r5 = 0x00000000 r6 = 0xc0bc91ac r7 = 0xe7ffffff r8 = 0xc4e6e640 r9 = 0xc0a8441c r10 = 0xde03a958 undefinedinstruction() at undefinedinstruction+0x1fc pc = 0xc0bc9458 lr = 0xc0bba3fc (exception_exit) sp = 0xde03a958 fp = 0xde03a9b0 r4 = 0xffffffff r5 = 0xffff1004 r6 = 0xc0cedecc r7 = 0xc0ccf088 r8 = 0xc4e6e640 r9 = 0xc0ccf010 r10 = 0xde03a9e4 exception_exit() at exception_exit pc = 0xc0bba3fc lr = 0xc0a84410 (kdb_enter+0x40) sp = 0xde03a9ac fp = 0xde03a9b0 r0 = 0xc0cdcaa4 r1 = 0x00000000 r2 = 0x00000000 r3 = 0x00000000 r4 = 0xc0c176d9 r5 = 0xc0c0a63a r6 = 0xc0cedecc r7 = 0xc0ccf088 r8 = 0xc4e6e640 r9 = 0xc0ccf010 r10 = 0xde03a9e4 r12 = 0x00000000 kdb_enter() at kdb_enter+0x50 pc = 0xc0a84420 lr = 0xc0a544d4 (panic+0xcc) sp = 0xde03a9b8 fp = 0xde03a9d8 r4 = 0x00000100 panic() at panic+0xcc pc = 0xc0a544d4 lr = 0xc098cea0 (bmap_truncate_mapping+0x408) sp = 0xde03a9f0 fp = 0xde03aae8 r4 = 0xc414f430 r5 = 0x00000000 r6 = 0x00000000 r7 = 0x00000000 r8 = 0xc414f378 r9 = 0xde03aa88 r10 = 0x00000098 bmap_truncate_mapping() at bmap_truncate_mapping+0x408 pc = 0xc098cea0 lr = 0xc098e374 (nandfs_bmap_truncate_mapping+0x78) sp = 0xde03aaf0 fp = 0xde03ab20 r4 = 0x00000000 r5 = 0x00000097 r6 = 0x00000000 r7 = 0x00000098 r8 = 0xc414f378 r9 = 0x00000000 r10 = 0x00000098 nandfs_bmap_truncate_mapping() at nandfs_bmap_truncate_mapping+0x78 pc = 0xc098e374 lr = 0xc09a0fb4 (nandfs_vinit+0x2b8) sp = 0xde03ab28 fp = 0xde03ab80 r4 = 0x00000000 r5 = 0x00000000 r6 = 0xc4509360 r7 = 0x00000000 r8 = 0x00000000 nandfs_vinit() at nandfs_vinit+0x2b8 pc = 0xc09a0fb4 lr = 0xc09a03c0 (nandfs_itimes+0x3404) sp = 0xde03ab88 fp = 0xde03ab98 r4 = 0xc414f378 r5 = 0xc4509360 r6 = 0x00000000 r7 = 0xc4333d20 r8 = 0xc4e6e640 r9 = 0xc45093c4 r10 = 0xc4509360 nandfs_itimes() at nandfs_itimes+0x3404 pc = 0xc09a03c0 lr = 0xc0be21b8 (VOP_INACTIVE_APV+0x9c) sp = 0xde03aba0 fp = 0xde03abb0 r4 = 0x00000000 r5 = 0xde03abc8 r6 = 0xc0ca0560 VOP_INACTIVE_APV() at VOP_INACTIVE_APV+0x9c pc = 0xc0be21b8 lr = 0xc0adc2e4 (vinactive+0xb0) sp = 0xde03abb8 fp = 0xde03abf0 r4 = 0xc4509360 r5 = 0x00000002 r6 = 0xc45093c4 vinactive() at vinactive+0xb0 pc = 0xc0adc2e4 lr = 0xc0adc5e4 (vrele+0x210) sp = 0xde03abf8 fp = 0xde03ac20 r4 = 0xc4509360 r5 = 0x00000002 r6 = 0xc45093c4 r7 = 0x00000000 r8 = 0x00000000 r9 = 0xde03ad74 vrele() at vrele+0x210 pc = 0xc0adc5e4 lr = 0xc0adc660 (vput+0x10) sp = 0xde03ac28 fp = 0xde03ac28 r4 = 0xde03acd8 r5 = 0xc4e6e640 r6 = 0x00000000 r7 = 0x00000000 vput() at vput+0x10 pc = 0xc0adc660 lr = 0xc0ae4bec (kern_unlinkat+0x1e4) sp = 0xde03ac30 fp = 0xde03ada8 kern_unlinkat() at kern_unlinkat+0x1e4 pc = 0xc0ae4bec lr = 0xc0ae47d8 (sys_unlink+0x24) sp = 0xde03adb0 fp = 0xde03adb8 r4 = 0xc4e6e640 r5 = 0xc498e000 r6 = 0x00000000 r7 = 0x00000000 r8 = 0xde03ae10 r9 = 0x00000001 r10 = 0x00000000 sys_unlink() at sys_unlink+0x24 pc = 0xc0ae47d8 lr = 0xc0bc8b6c (swi_handler+0x224) sp = 0xde03adc0 fp = 0xde03ae58 swi_handler() at swi_handler+0x224 pc = 0xc0bc8b6c lr = 0xc0bba1c8 (swi_entry+0x40) sp = 0xde03ae60 fp = 0xbfffea58 r4 = 0x20c0a364 r5 = 0x20c0a2a0 r6 = 0x20c9f114 r7 = 0x0000000a r8 = 0x20c0a200 swi_entry() at swi_entry+0x40 pc = 0xc0bba1c8 lr = 0xc0bba1c8 (swi_entry+0x40) sp = 0xde03ae60 fp = 0xbfffea58 Unable to unwind further db> From owner-freebsd-arm@FreeBSD.ORG Fri Sep 20 22:45:51 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 76D20E7B for ; Fri, 20 Sep 2013 22:45:51 +0000 (UTC) (envelope-from david.cheney@canonical.com) Received: from mail-la0-f48.google.com (mail-la0-f48.google.com [209.85.215.48]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id DEDDA2707 for ; Fri, 20 Sep 2013 22:45:50 +0000 (UTC) Received: by mail-la0-f48.google.com with SMTP id er20so841346lab.35 for ; Fri, 20 Sep 2013 15:45:48 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=l/QltLiI6peQvMtbBiXGrMG1teJwpGY1qgD+NDNItkg=; b=jto3EW5LILp4o4guMRFEgVKpfSJpj/GD4r4ppXk9dyZnIPwSFT+HZPL3hEm3vghQmR 57vgzdtl5iKS07fJm824T37Mrg0OPPoq1iUeMLeKYJTdrdi0t8BXsZblRDPvJFMxahs7 9gYwcgjhp9CoAjgZqoCYJNlrEEKe7XplzvcyC5BANh0QuEAU3ZOFI+y3w1w4+mgqUsyJ H9DfuB2PAn+e4BL7ZOEcNLeTuvBxn6zZOwduJRdHG3YFiVlllJFbzkAqifmpbD0CoZ2y nz437daqwInkHGq1vd0iIPas0A0fjaRTOy0TIfIaEPaGx9LPaIySeVapJzZthY3yAv9k Hu6Q== X-Gm-Message-State: ALoCoQnbZ+ou7/77o9Vs8tBhbYxtcgMocSJQpNH+r5WBMDs2iifIwwz8YCD3Dx3BPsX+UJjqS+yG MIME-Version: 1.0 X-Received: by 10.112.198.39 with SMTP id iz7mr8110065lbc.24.1379717148579; Fri, 20 Sep 2013 15:45:48 -0700 (PDT) Received: by 10.114.183.47 with HTTP; Fri, 20 Sep 2013 15:45:48 -0700 (PDT) Date: Sat, 21 Sep 2013 08:45:48 +1000 Message-ID: Subject: freebsd on beaglebone black, lock reversal panic shortly after first boot From: David Cheney To: freebsd-arm@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Sep 2013 22:45:51 -0000 Hello, I've been trying to replace my old RPi freebsd system, which I haven't been able to get a working build for months on, with a Beaglebone Black. This was the message I received after booting the card for the first time and trying to portsnap. Cheers Dave --- FreeBSD/arm (beaglebone) (ttyu0) login: root Sep 20 21:57:34 beaglebone login: ROOT LOGIN (root) ON ttyu0 FreeBSD 10.0-ALPHA2 (BEAGLEBONE) #0 r255662: Fri Sep 20 23:04:55 EST 2013 Welcome to FreeBSD! Before seeking technical support, please use the following resources: o Security advisories and updated errata information for all releases are at http://www.FreeBSD.org/releases/ - always consult the ERRATA section for your release first as it's updated frequently. o The Handbook and FAQ documents are at http://www.FreeBSD.org/ and, along with the mailing lists, can be searched by going to http://www.FreeBSD.org/search/. If the doc package has been installed (or fetched via pkg install lang-freebsd-doc, where lang is the 2-letter language code, e.g. en), they are also available formatted in /usr/local/share/doc/freebsd. If you still have a question or problem, please take the output of `uname -a', along with any relevant error messages, and email it as a question to the questions@FreeBSD.org mailing list. If you are unfamiliar with FreeBSD's directory layout, please refer to the hier(7) manual page. If you are not familiar with manual pages, type `man man'. Edit /etc/motd to change this login announcement. root@beaglebone:~ # df -h Filesystem Size Used Avail Capacity Mounted on /dev/mmcsd0s2a 3.5G 396M 2.9G 12% / devfs 1.0k 1.0k 0B 100% /dev /dev/mmcsd0s1 2M 693k 1.3M 34% /boot/msdos /dev/md0 28M 24k 26M 0% /tmp /dev/md1 14M 60k 13M 0% /var/log /dev/md2 4.4M 8.0k 4.0M 0% /var/tmp root@beaglebone:~ # portsnap fetch && portsnap extract Looking up portsnap.FreeBSD.org mirrors... 7 mirrors found. Fetching public key from ec2-ap-southeast-2.portsnap.freebsd.org... done. Fetching snapshot tag from ec2-ap-southeast-2.portsnap.freebsd.org... done. Fetching snapshot metadata... done. Fetching snapshot generated at Fri Sep 20 00:08:00 UTC 2013: f88e945869b296b518253a080d33b8c988a382fd82586c100% of 69 MB 1473 kBps 00m48s Extracting snapshot... lock order reversal: 1st 0xcd1299d0 bufwait (bufwait) @ /root/crochet-freebsd/src/sys/kern/vfs_bio.c:3059 2nd 0xc2a8f600 dirhash (dirhash) @ /root/crochet-freebsd/src/sys/ufs/ufs/ufs_dirhash.c:284 KDB: stack backtrace: db_trace_self() at db_trace_self pc = 0xc052ecf4 lr = 0xc022dcd0 (db_trace_self_wrapper+0x30) sp = 0xdd6ff7e0 fp = 0xdd6ff8f8 r10 = 0xcd1299d0 db_trace_self_wrapper() at db_trace_self_wrapper+0x30 pc = 0xc022dcd0 lr = 0xc038e9e0 (kdb_backtrace+0x38) sp = 0xdd6ff900 fp = 0xdd6ff908 r4 = 0xc066a484 r5 = 0xc05ae078 r6 = 0xc0592f71 r7 = 0xc0598518 kdb_backtrace() at kdb_backtrace+0x38 pc = 0xc038e9e0 lr = 0xc03a8b5c (witness_checkorder+0xda0) sp = 0xdd6ff910 fp = 0xdd6ff960 r4 = 0xc05ae43b witness_checkorder() at witness_checkorder+0xda0 pc = 0xc03a8b5c lr = 0xc035ff8c (_sx_xlock+0x84) sp = 0xdd6ff968 fp = 0xdd6ff990 r4 = 0x0000011c r5 = 0xc05ae075 r6 = 0xc2a8f610 r7 = 0xc2a8f600 r8 = 0x00000000 r9 = 0xc2c067e0 r10 = 0x000001b4 _sx_xlock() at _sx_xlock+0x84 pc = 0xc035ff8c lr = 0xc04ebfa8 (ufsdirhash_add+0x34) sp = 0xdd6ff998 fp = 0xdd6ff9b0 r4 = 0xc2a8f600 r5 = 0xc2ab1e80 r6 = 0xdd6ffa48 r7 = 0x00000001 r8 = 0x0000084c ufsdirhash_add() at ufsdirhash_add+0x34 pc = 0xc04ebfa8 lr = 0xc04ee88c (ufs_direnter+0x45c) sp = 0xdd6ff9b8 fp = 0xdd6ffa20 r4 = 0xc2ab1e80 r5 = 0xcd3af84c r6 = 0xdd6ffa48 r7 = 0x00000001 r8 = 0x0000004c r9 = 0xc2c067e0 ufs_direnter() at ufs_direnter+0x45c pc = 0xc04ee88c lr = 0xc04f7e04 (ufs_makeinode+0x3f4) sp = 0xdd6ffa28 fp = 0xdd6ffb88 r4 = 0xdd6ffa48 r5 = 0xc2ab1180 r6 = 0xdd6ffd48 r7 = 0x00000000 r8 = 0xc2c067e0 r9 = 0xdd6ffd30 r10 = 0x000081a4 ufs_makeinode() at ufs_makeinode+0x3f4 pc = 0xc04f7e04 lr = 0xc04f4268 (ufs_create+0x24) sp = 0xdd6ffb90 fp = 0xdd6ffb90 r4 = 0xdd6ffc60 r5 = 0xc064eba0 r6 = 0x00000000 r7 = 0x00100a02 r8 = 0x00000000 r9 = 0xdd6ffd30 r10 = 0xdd6ffd50 ufs_create() at ufs_create+0x24 pc = 0xc04f4268 lr = 0xc0552268 (VOP_CREATE_APV+0xd0) sp = 0xdd6ffb98 fp = 0xdd6ffba8 VOP_CREATE_APV() at VOP_CREATE_APV+0xd0 pc = 0xc0552268 lr = 0xc0408540 (vn_open_cred+0x278) sp = 0xdd6ffbb0 fp = 0xdd6ffc90 r4 = 0xdd6ffce0 r5 = 0xdd6ffd30 r6 = 0xc2c067e0 vn_open_cred() at vn_open_cred+0x278 pc = 0xc0408540 lr = 0xc04082c0 (vn_open+0x24) sp = 0xdd6ffc98 fp = 0xdd6ffca0 r4 = 0xc2a2d640 r5 = 0xc2a76000 r6 = 0xdd6ffce0 r7 = 0x00000012 r8 = 0x00000000 r9 = 0x000500cf r10 = 0xdd6ffcd0 vn_open() at vn_open+0x24 pc = 0xc04082c0 lr = 0xc040187c (kern_openat+0x24c) sp = 0xdd6ffca8 fp = 0xdd6ffda8 kern_openat() at kern_openat+0x24c pc = 0xc040187c lr = 0xc04015c4 (sys_open+0x28) sp = 0xdd6ffdb0 fp = 0xdd6ffdb8 r4 = 0xc2a2d640 r5 = 0x00000000 r6 = 0x20cc1198 r7 = 0x00000000 r8 = 0xdd6ffe10 r9 = 0xc29f6c80 r10 = 0x20c24080 sys_open() at sys_open+0x28 pc = 0xc04015c4 lr = 0xc0540764 (swi_handler+0x284) sp = 0xdd6ffdc0 fp = 0xdd6ffe58 swi_handler() at swi_handler+0x284 pc = 0xc0540764 lr = 0xc0530350 (swi_entry+0x2c) sp = 0xdd6ffe60 fp = 0xbfffe960 r4 = 0x20c0a200 r5 = 0x000001a4 r6 = 0x20cc1198 r7 = 0x00000005 r8 = 0x20c0a200 r9 = 0x00000001 swi_entry() at swi_entry+0x2c pc = 0xc0530350 lr = 0xc0530350 (swi_entry+0x2c) sp = 0xdd6ffe60 fp = 0xbfffe960 Unable to unwind further lock order reversal: 1st 0xc2c06814 ufs (ufs) @ /root/crochet-freebsd/src/sys/kern/vfs_subr.c:2099 2nd 0xcd1299d0 bufwait (bufwait) @ /root/crochet-freebsd/src/sys/ufs/ffs/ffs_vnops.c:262 3rd 0xc2cb9154 ufs (ufs) @ /root/crochet-freebsd/src/sys/kern/vfs_subr.c:2099 KDB: stack backtrace: db_trace_self() at db_trace_self pc = 0xc052ecf4 lr = 0xc022dcd0 (db_trace_self_wrapper+0x30) sp = 0xdd6ff578 fp = 0xdd6ff690 r10 = 0xc05adb30 db_trace_self_wrapper() at db_trace_self_wrapper+0x30 pc = 0xc022dcd0 lr = 0xc038e9e0 (kdb_backtrace+0x38) sp = 0xdd6ff698 fp = 0xdd6ff6a0 r4 = 0xc066a484 r5 = 0xc0592f71 r6 = 0xc059b3d0 r7 = 0xc05adb33 kdb_backtrace() at kdb_backtrace+0x38 pc = 0xc038e9e0 lr = 0xc03a8b5c (witness_checkorder+0xda0) sp = 0xdd6ff6a8 fp = 0xdd6ff6f8 r4 = 0xc0581d1c witness_checkorder() at witness_checkorder+0xda0 pc = 0xc03a8b5c lr = 0xc033c5fc (__lockmgr_args+0x698) sp = 0xdd6ff700 fp = 0xdd6ff768 r4 = 0x00080100 r5 = 0x00000833 r6 = 0xc2cb9154 r7 = 0x00080000 r8 = 0x00000100 r9 = 0x00000000 r10 = 0xc059b3cd __lockmgr_args() at __lockmgr_args+0x698 pc = 0xc033c5fc lr = 0xc04e678c (ffs_lock+0x80) sp = 0xdd6ff770 fp = 0xdd6ff798 r4 = 0xdd6ff7b8 r5 = 0x00080100 r6 = 0xc2cb9120 r7 = 0xc2cb9154 r8 = 0xc2cb9174 r9 = 0x00000000 r10 = 0xc059b3cd ffs_lock() at ffs_lock+0x80 pc = 0xc04e678c lr = 0xc0554118 (VOP_LOCK1_APV+0xd8) sp = 0xdd6ff7a0 fp = 0xdd6ff7b0 r4 = 0xdd6ff7b8 r5 = 0xc064e690 r6 = 0x00000000 r7 = 0x00000000 r8 = 0xc2a2d640 r9 = 0x00000833 VOP_LOCK1_APV() at VOP_LOCK1_APV+0xd8 pc = 0xc0554118 lr = 0xc0408cbc (_vn_lock+0x78) sp = 0xdd6ff7b8 fp = 0xdd6ff7e8 r4 = 0xc2cb9120 r5 = 0x00080100 r6 = 0x00080100 _vn_lock() at _vn_lock+0x78 pc = 0xc0408cbc lr = 0xc03f97e8 (vget+0x60) sp = 0xdd6ff7f0 fp = 0xdd6ff810 r4 = 0xc2cb9120 r5 = 0x00000000 r6 = 0x00080100 r7 = 0x00000000 r8 = 0xc2a2d640 r9 = 0xc059a607 r10 = 0x00000000 vget() at vget+0x60 pc = 0xc03f97e8 lr = 0xc03ede5c (vfs_hash_get+0xe4) sp = 0xdd6ff818 fp = 0xdd6ff848 r4 = 0xc2a0b2b0 r5 = 0x00000000 r6 = 0x0002787d r7 = 0x00000000 r8 = 0xc2cb9120 vfs_hash_get() at vfs_hash_get+0xe4 pc = 0xc03ede5c lr = 0xc04e17f4 (ffs_vgetf+0x3c) sp = 0xdd6ff850 fp = 0xdd6ff8a0 r4 = 0x0002787d r5 = 0xc05aa74b r6 = 0xc2bb13c0 r7 = 0xdd6ff908 r8 = 0xc2bb13c0 r9 = 0x00080000 r10 = 0xc2a0b2b0 ffs_vgetf() at ffs_vgetf+0x3c pc = 0xc04e17f4 lr = 0xc04da468 (softdep_sync_buf+0x974) sp = 0xdd6ff8a8 fp = 0xdd6ff928 r4 = 0x0002787d r5 = 0xc05aa74b r6 = 0xc2bb13c0 r7 = 0xc05aa74b r8 = 0xc2bb13c0 r9 = 0x0000088b r10 = 0x0002787d softdep_sync_buf() at softdep_sync_buf+0x974 pc = 0xc04da468 lr = 0xc04e7560 (ffs_syncvnode+0x2bc) sp = 0xdd6ff930 fp = 0xdd6ff980 r4 = 0x00000000 r5 = 0xcd188d48 r6 = 0x00060200 r7 = 0xc2c067e0 r8 = 0xc05adb30 r9 = 0xcd1299d0 r10 = 0xcd129978 ffs_syncvnode() at ffs_syncvnode+0x2bc pc = 0xc04e7560 lr = 0xc04e6650 (ffs_fsync+0x20) sp = 0xdd6ff988 fp = 0xdd6ff998 r4 = 0xdd6ff9f0 r5 = 0xc2c067e0 r6 = 0x00000000 r7 = 0x00000200 r8 = 0xc2a2d640 r9 = 0xc2c067e0 r10 = 0xc33445a0 ffs_fsync() at ffs_fsync+0x20 pc = 0xc04e6650 lr = 0xc05534b8 (VOP_FSYNC_APV+0xd0) sp = 0xdd6ff9a0 fp = 0xdd6ff9b0 r4 = 0xdd6ff9f0 r5 = 0xc064e690 r6 = 0x00000000 r7 = 0x00000200 VOP_FSYNC_APV() at VOP_FSYNC_APV+0xd0 pc = 0xc05534b8 lr = 0xc04eeb54 (ufs_direnter+0x724) sp = 0xdd6ff9b8 fp = 0xdd6ffa20 r4 = 0xc33445a0 r5 = 0x00000000 r6 = 0xcd356e00 ufs_direnter() at ufs_direnter+0x724 pc = 0xc04eeb54 lr = 0xc04f7e04 (ufs_makeinode+0x3f4) sp = 0xdd6ffa28 fp = 0xdd6ffb88 r4 = 0xdd6ffa48 r5 = 0xc332fa00 r6 = 0xdd6ffd48 r7 = 0x00000000 r8 = 0xc2c067e0 r9 = 0xdd6ffd30 r10 = 0x000081a4 ufs_makeinode() at ufs_makeinode+0x3f4 pc = 0xc04f7e04 lr = 0xc04f4268 (ufs_create+0x24) sp = 0xdd6ffb90 fp = 0xdd6ffb90 r4 = 0xdd6ffc60 r5 = 0xc064eba0 r6 = 0x00000000 r7 = 0x00100a02 r8 = 0x00000000 r9 = 0xdd6ffd30 r10 = 0xdd6ffd50 ufs_create() at ufs_create+0x24 pc = 0xc04f4268 lr = 0xc0552268 (VOP_CREATE_APV+0xd0) sp = 0xdd6ffb98 fp = 0xdd6ffba8 VOP_CREATE_APV() at VOP_CREATE_APV+0xd0 pc = 0xc0552268 lr = 0xc0408540 (vn_open_cred+0x278) sp = 0xdd6ffbb0 fp = 0xdd6ffc90 r4 = 0xdd6ffce0 r5 = 0xdd6ffd30 r6 = 0xc2c067e0 vn_open_cred() at vn_open_cred+0x278 pc = 0xc0408540 lr = 0xc04082c0 (vn_open+0x24) sp = 0xdd6ffc98 fp = 0xdd6ffca0 r4 = 0xc2a2d640 r5 = 0xc2a76000 r6 = 0xdd6ffce0 r7 = 0x00000012 r8 = 0x00000000 r9 = 0x000500cf r10 = 0xdd6ffcd0 vn_open() at vn_open+0x24 pc = 0xc04082c0 lr = 0xc040187c (kern_openat+0x24c) sp = 0xdd6ffca8 fp = 0xdd6ffda8 kern_openat() at kern_openat+0x24c pc = 0xc040187c lr = 0xc04015c4 (sys_open+0x28) sp = 0xdd6ffdb0 fp = 0xdd6ffdb8 r4 = 0xc2a2d640 r5 = 0x00000000 r6 = 0x20cc1198 r7 = 0x00000000 r8 = 0xdd6ffe10 r9 = 0xc29f6c80 r10 = 0x20c24080 sys_open() at sys_open+0x28 pc = 0xc04015c4 lr = 0xc0540764 (swi_handler+0x284) sp = 0xdd6ffdc0 fp = 0xdd6ffe58 swi_handler() at swi_handler+0x284 pc = 0xc0540764 lr = 0xc0530350 (swi_entry+0x2c) sp = 0xdd6ffe60 fp = 0xbfffe960 r4 = 0x20c0a200 r5 = 0x000001a4 r6 = 0x20cc1198 r7 = 0x00000 From owner-freebsd-arm@FreeBSD.ORG Sat Sep 21 00:49:21 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id C5749AA3 for ; Sat, 21 Sep 2013 00:49:21 +0000 (UTC) (envelope-from george+freebsd@m5p.com) Received: from mailhost.m5p.com (ip-2-1-0-2.r03.asbnva02.us.ce.gin.ntt.net [IPv6:2001:418:0:5000::16]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 634C22CDE for ; Sat, 21 Sep 2013 00:49:21 +0000 (UTC) Received: from wonderland.m5p.com (localhost [IPv6:::1]) by mailhost.m5p.com (8.14.5/8.14.5) with ESMTP id r8L0nDCj072679 for ; Fri, 20 Sep 2013 20:49:18 -0400 (EDT) (envelope-from george+freebsd@m5p.com) Message-ID: <523CED09.2010509@m5p.com> Date: Fri, 20 Sep 2013 20:49:13 -0400 From: George Mitchell User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130716 Thunderbird/17.0.7 MIME-Version: 1.0 To: "freebsd-arm@freebsd.org" Subject: Progress on Raspberry Pi Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.73 on 10.100.0.3 X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.7 (mailhost.m5p.com [IPv6:::1]); Fri, 20 Sep 2013 20:49:19 -0400 (EDT) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Sep 2013 00:49:21 -0000 My AdaFruit serial cable arrived, so now I can gather useful information when my RPi crashes (which is still happening fairly often as I try to build print/cups, having started five days ago and still not having gotten through ghostscript). I built my image with crochet on an amd64 running r255361, and the image itself is based on that version. (However, in sys/arm/arm I updated pmap-v6.c to 255612 and stdatomic.c to 255613. I see they have been updated again within the last day; perhaps I should try again.) /etc/src.conf: MALLOC_PRODUCTION=yes /etc/make.conf: WITH_PKGNG=yes MALLOC_PRODUCTION=yes # added by use.perl 2013-08-20 10:11:49 PERL_VERSION=5.14.4 I commented out the five syscons-related lines in sys/arm/conf/RPI-B so I could use the serial port. My SDHC card is apparently on the hairy edge of working, so I definitely needed /boot/loader.conf to contain: hw.bcm2835.sdhci.hs=0. Before I added that, I ended up with the dreaded error 19 and a manual mountroot prompt, at which point mountroot would accept a character from the serial input about 1/4 of the time. Other serial input works without a problem. Before I remembered to comment out the /dev/ttyvN lines in /etc/tty, I naturally saw getty errors on the nonexistent devices, but I would also randomly get an "Interrupted system call" on /dev/ttyu0, followed by a long pause, followed (finally) by a login prompt. After I commented out the ttyvN lines, the "Interrupted system call" error on /dev/ttyu0 went away. Questions: 1. Do we have any sort of a memory test for the RPi? It seems unlikely that I have a hardware problem, but I would like to rule it out. 2. Now that I can do something when I get the prefetch abort or panic, what should I do at the "db>" prompt to help debug it? It's happening about five or six times a day. Again, my thanks to all the developers! -- George From owner-freebsd-arm@FreeBSD.ORG Sat Sep 21 01:16:18 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id A8C1DFC7 for ; Sat, 21 Sep 2013 01:16:18 +0000 (UTC) (envelope-from lists.br@gmail.com) Received: from mail-lb0-x231.google.com (mail-lb0-x231.google.com [IPv6:2a00:1450:4010:c04::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 1B2BC2DFE for ; Sat, 21 Sep 2013 01:16:17 +0000 (UTC) Received: by mail-lb0-f177.google.com with SMTP id w7so1089002lbi.8 for ; Fri, 20 Sep 2013 18:16:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Yr1gOwZ9/6CyhlyZZsIkJx0rFxw+8zFXHLlXbqTmcMM=; b=q+pkbA/t5P4+5IQ1aAxijbY5y8Sc06GzQeiDchNlr1GFNBbQPaPeZXWym60phXJvC8 YkJfppETAq4y3OfyhavA8R60FSZUHfzhWkcefSr3zYENlbZl0l0IMLmDXXWCuni5TyV0 Yu3k0stcvIBxW5BnLqTVPPWOO+7bKv7+/ptcRNCSiHteQKKzX7qnTkH1rT4tD6SpHTRS 1fpy1mj0sP/8zdCo00yo9TjXpSIa5du3qSkgScTmnauCyU47JhxT0/LXgQ4GJkxtnXmu +CDbUQBgpfEARPq4PVkgT2GWTKUSP3eaMdJBpi9HebkMcCUQaAbFxuz8oqKu80KBtnqA mHEw== MIME-Version: 1.0 X-Received: by 10.112.146.33 with SMTP id sz1mr8527404lbb.14.1379726175451; Fri, 20 Sep 2013 18:16:15 -0700 (PDT) Received: by 10.112.147.197 with HTTP; Fri, 20 Sep 2013 18:16:15 -0700 (PDT) In-Reply-To: <523CED09.2010509@m5p.com> References: <523CED09.2010509@m5p.com> Date: Fri, 20 Sep 2013 22:16:15 -0300 Message-ID: Subject: Re: Progress on Raspberry Pi From: Luiz Otavio O Souza To: George Mitchell Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Sep 2013 01:16:18 -0000 On 20 September 2013 21:49, George Mitchell wrote: > My AdaFruit serial cable arrived, so now I can gather useful information > when my RPi crashes (which is still happening fairly often as I try to > build print/cups, having started five days ago and still not having > gotten through ghostscript). > > I built my image with crochet on an amd64 running r255361, and the image > itself is based on that version. (However, in sys/arm/arm I updated > pmap-v6.c to 255612 and stdatomic.c to 255613. I see they have been > updated again within the last day; perhaps I should try again.) > > /etc/src.conf: > MALLOC_PRODUCTION=yes > MALLOC_PRODUCTION=yes is just a workaround for the RPi problem, in a ideal world (where everything works) we wouldn't need to set it. > > /etc/make.conf: > WITH_PKGNG=yes > MALLOC_PRODUCTION=yes > # added by use.perl 2013-08-20 10:11:49 > PERL_VERSION=5.14.4 > > I commented out the five syscons-related lines in sys/arm/conf/RPI-B so > I could use the serial port. My SDHC card is apparently on the hairy > edge of working, so I definitely needed /boot/loader.conf to contain: > hw.bcm2835.sdhci.hs=0. Before I added that, I ended up with the dreaded > error 19 and a manual mountroot prompt, at which point mountroot would > accept a character from the serial input about 1/4 of the time. Other > serial input works without a problem. > Can you check if the patch on arm/179688 ( http://www.freebsd.org/cgi/query-pr.cgi?pr=arm/179688) fix the mountroot input problem for you ? > > Before I remembered to comment out the /dev/ttyvN lines in /etc/tty, I > naturally saw getty errors on the nonexistent devices, but I would also > randomly get an "Interrupted system call" on /dev/ttyu0, followed by a > long pause, followed (finally) by a login prompt. After I commented out > the ttyvN lines, the "Interrupted system call" error on /dev/ttyu0 went > away. > This is added by crochet, isn't ? (boards/RaspberryPi/overlay/etc/ttys) > > Questions: > > 1. Do we have any sort of a memory test for the RPi? It seems unlikely > that I have a hardware problem, but I would like to rule it out. > 2. Now that I can do something when I get the prefetch abort or panic, > what should I do at the "db>" prompt to help debug it? It's happening > about five or six times a day. > > We have a known bug that triggers under heavy load (during builds): http://www.freebsd.org/cgi/query-pr.cgi?pr=arm/182060 We need to check (now that gcc builds should be working again for arm) if there is any difference between the builds with clang and gcc, oabi and eabi. Thanks, Luiz From owner-freebsd-arm@FreeBSD.ORG Sat Sep 21 01:22:01 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 06AEE9D for ; Sat, 21 Sep 2013 01:22:01 +0000 (UTC) (envelope-from george+freebsd@m5p.com) Received: from mailhost.m5p.com (ip-2-1-0-2.r03.asbnva02.us.ce.gin.ntt.net [IPv6:2001:418:0:5000::16]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id C0DCF2E41 for ; Sat, 21 Sep 2013 01:22:00 +0000 (UTC) Received: from wonderland.m5p.com (localhost [IPv6:::1]) by mailhost.m5p.com (8.14.5/8.14.5) with ESMTP id r8L1LsId072900; Fri, 20 Sep 2013 21:21:59 -0400 (EDT) (envelope-from george+freebsd@m5p.com) Message-ID: <523CF4B2.6030409@m5p.com> Date: Fri, 20 Sep 2013 21:21:54 -0400 From: George Mitchell User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130716 Thunderbird/17.0.7 MIME-Version: 1.0 To: Luiz Otavio O Souza Subject: Re: Progress on Raspberry Pi References: <523CED09.2010509@m5p.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.73 on 10.100.0.3 X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.7 (mailhost.m5p.com [IPv6:::1]); Fri, 20 Sep 2013 21:21:59 -0400 (EDT) Cc: "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Sep 2013 01:22:01 -0000 On 09/20/13 21:16, Luiz Otavio O Souza wrote: > On 20 September 2013 21:49, George Mitchell > wrote: > > My AdaFruit serial cable arrived, so now I can gather useful information > when my RPi crashes (which is still happening fairly often as I try to > build print/cups, having started five days ago and still not having > gotten through ghostscript). > > I built my image with crochet on an amd64 running r255361, and the image > itself is based on that version. (However, in sys/arm/arm I updated > pmap-v6.c to 255612 and stdatomic.c to 255613. I see they have been > updated again within the last day; perhaps I should try again.) > > /etc/src.conf: > MALLOC_PRODUCTION=yes > > > MALLOC_PRODUCTION=yes is just a workaround for the RPi problem, in a > ideal world (where everything works) we wouldn't need to set it. > > > /etc/make.conf: > WITH_PKGNG=yes > MALLOC_PRODUCTION=yes > # added by use.perl 2013-08-20 10:11:49 > PERL_VERSION=5.14.4 > > I commented out the five syscons-related lines in sys/arm/conf/RPI-B so > I could use the serial port. My SDHC card is apparently on the hairy > edge of working, so I definitely needed /boot/loader.conf to contain: > hw.bcm2835.sdhci.hs=0. Before I added that, I ended up with the dreaded > error 19 and a manual mountroot prompt, at which point mountroot would > accept a character from the serial input about 1/4 of the time. Other > serial input works without a problem. > > > Can you check if the patch on arm/179688 > (http://www.freebsd.org/cgi/query-pr.cgi?pr=arm/179688) fix the > mountroot input problem for you ? I'll try that. > > > Before I remembered to comment out the /dev/ttyvN lines in /etc/tty, I > naturally saw getty errors on the nonexistent devices, but I would also > randomly get an "Interrupted system call" on /dev/ttyu0, followed by a > long pause, followed (finally) by a login prompt. After I commented out > the ttyvN lines, the "Interrupted system call" error on /dev/ttyu0 went > away. > > > This is added by crochet, isn't ? (boards/RaspberryPi/overlay/etc/ttys) > > > Questions: > > 1. Do we have any sort of a memory test for the RPi? It seems unlikely > that I have a hardware problem, but I would like to rule it out. > > > 2. Now that I can do something when I get the prefetch abort or panic, > what should I do at the "db>" prompt to help debug it? It's happening > about five or six times a day. > > > We have a known bug that triggers under heavy load (during builds): > http://www.freebsd.org/cgi/query-pr.cgi?pr=arm/182060 > > We need to check (now that gcc builds should be working again for arm) > if there is any difference between the builds with clang and gcc, oabi > and eabi. > > Thanks, > Luiz Back in January, gcc worked fine. More recently, not so fine, and I finally gave up and plunged into the clang/EABI world. It mostly works aside from my crashes. -- George From owner-freebsd-arm@FreeBSD.ORG Sat Sep 21 09:48:08 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id E639B458 for ; Sat, 21 Sep 2013 09:48:08 +0000 (UTC) (envelope-from ronald-freebsd8@klop.yi.org) Received: from cpsmtpb-ews02.kpnxchange.com (cpsmtpb-ews02.kpnxchange.com [213.75.39.5]) by mx1.freebsd.org (Postfix) with ESMTP id 3C92924BF for ; Sat, 21 Sep 2013 09:48:06 +0000 (UTC) Received: from cpsps-ews22.kpnxchange.com ([10.94.84.188]) by cpsmtpb-ews02.kpnxchange.com with Microsoft SMTPSVC(7.5.7601.17514); Sat, 21 Sep 2013 11:46:55 +0200 Received: from CPSMTPM-TLF101.kpnxchange.com ([195.121.3.4]) by cpsps-ews22.kpnxchange.com with Microsoft SMTPSVC(7.5.7601.17514); Sat, 21 Sep 2013 11:46:55 +0200 Received: from sjakie.klop.ws ([212.182.167.131]) by CPSMTPM-TLF101.kpnxchange.com with Microsoft SMTPSVC(7.5.7601.17514); Sat, 21 Sep 2013 11:46:55 +0200 Received: from 212-182-167-131.ip.telfort.nl (localhost [127.0.0.1]) by sjakie.klop.ws (Postfix) with ESMTP id F36E2BF30 for ; Sat, 21 Sep 2013 11:46:54 +0200 (CEST) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes To: freebsd-arm@freebsd.org Subject: Re: freebsd on beaglebone black, lock reversal panic shortly after first boot References: Date: Sat, 21 Sep 2013 11:46:54 +0200 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Ronald Klop" Message-ID: In-Reply-To: User-Agent: Opera Mail/12.16 (FreeBSD) X-OriginalArrivalTime: 21 Sep 2013 09:46:55.0440 (UTC) FILETIME=[81D9F500:01CEB6AF] X-RcptDomain: freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Sep 2013 09:48:09 -0000 On Sat, 21 Sep 2013 00:45:48 +0200, David Cheney wrote: > Hello, > > I've been trying to replace my old RPi freebsd system, which I haven't > been able to get a working build for months on, with a Beaglebone > Black. This was the message I received after booting the card for the > first time and trying to portsnap. > > Cheers > > Dave In the subject you mention it is a panic, but that does not show from the output. Is your machine hanging? Or does it reboot after the panic? Or can you just work on. There are a lot of lock order reversals (LORs) which are harmless for the working of the machine. I don't know about this one. Ronald. > > --- > > > FreeBSD/arm (beaglebone) (ttyu0) > > login: root > Sep 20 21:57:34 beaglebone login: ROOT LOGIN (root) ON ttyu0 > FreeBSD 10.0-ALPHA2 (BEAGLEBONE) #0 r255662: Fri Sep 20 23:04:55 EST 2013 > > Welcome to FreeBSD! > > Before seeking technical support, please use the following resources: > > o Security advisories and updated errata information for all releases > are > at http://www.FreeBSD.org/releases/ - always consult the ERRATA > section > for your release first as it's updated frequently. > > o The Handbook and FAQ documents are at http://www.FreeBSD.org/ and, > along with the mailing lists, can be searched by going to > http://www.FreeBSD.org/search/. If the doc package has been installed > (or fetched via pkg install lang-freebsd-doc, where lang is the > 2-letter language code, e.g. en), they are also available formatted > in /usr/local/share/doc/freebsd. > > If you still have a question or problem, please take the output of > `uname -a', along with any relevant error messages, and email it > as a question to the questions@FreeBSD.org mailing list. If you are > unfamiliar with FreeBSD's directory layout, please refer to the hier(7) > manual page. If you are not familiar with manual pages, type `man man'. > > Edit /etc/motd to change this login announcement. > > root@beaglebone:~ # df -h > Filesystem Size Used Avail Capacity Mounted on > /dev/mmcsd0s2a 3.5G 396M 2.9G 12% / > devfs 1.0k 1.0k 0B 100% /dev > /dev/mmcsd0s1 2M 693k 1.3M 34% /boot/msdos > /dev/md0 28M 24k 26M 0% /tmp > /dev/md1 14M 60k 13M 0% /var/log > /dev/md2 4.4M 8.0k 4.0M 0% /var/tmp > root@beaglebone:~ # portsnap fetch && portsnap extract > Looking up portsnap.FreeBSD.org mirrors... 7 mirrors found. > Fetching public key from ec2-ap-southeast-2.portsnap.freebsd.org... done. > Fetching snapshot tag from ec2-ap-southeast-2.portsnap.freebsd.org... > done. > Fetching snapshot metadata... done. > Fetching snapshot generated at Fri Sep 20 00:08:00 UTC 2013: > f88e945869b296b518253a080d33b8c988a382fd82586c100% of 69 MB 1473 kBps > 00m48s > Extracting snapshot... lock order reversal: > 1st 0xcd1299d0 bufwait (bufwait) @ > /root/crochet-freebsd/src/sys/kern/vfs_bio.c:3059 > 2nd 0xc2a8f600 dirhash (dirhash) @ > /root/crochet-freebsd/src/sys/ufs/ufs/ufs_dirhash.c:284 > KDB: stack backtrace: > db_trace_self() at db_trace_self > pc = 0xc052ecf4 lr = 0xc022dcd0 (db_trace_self_wrapper+0x30) > sp = 0xdd6ff7e0 fp = 0xdd6ff8f8 > r10 = 0xcd1299d0 > db_trace_self_wrapper() at db_trace_self_wrapper+0x30 > pc = 0xc022dcd0 lr = 0xc038e9e0 (kdb_backtrace+0x38) > sp = 0xdd6ff900 fp = 0xdd6ff908 > r4 = 0xc066a484 r5 = 0xc05ae078 > r6 = 0xc0592f71 r7 = 0xc0598518 > kdb_backtrace() at kdb_backtrace+0x38 > pc = 0xc038e9e0 lr = 0xc03a8b5c (witness_checkorder+0xda0) > sp = 0xdd6ff910 fp = 0xdd6ff960 > r4 = 0xc05ae43b > witness_checkorder() at witness_checkorder+0xda0 > pc = 0xc03a8b5c lr = 0xc035ff8c (_sx_xlock+0x84) > sp = 0xdd6ff968 fp = 0xdd6ff990 > r4 = 0x0000011c r5 = 0xc05ae075 > r6 = 0xc2a8f610 r7 = 0xc2a8f600 > r8 = 0x00000000 r9 = 0xc2c067e0 > r10 = 0x000001b4 > _sx_xlock() at _sx_xlock+0x84 > pc = 0xc035ff8c lr = 0xc04ebfa8 (ufsdirhash_add+0x34) > sp = 0xdd6ff998 fp = 0xdd6ff9b0 > r4 = 0xc2a8f600 r5 = 0xc2ab1e80 > r6 = 0xdd6ffa48 r7 = 0x00000001 > r8 = 0x0000084c > ufsdirhash_add() at ufsdirhash_add+0x34 > pc = 0xc04ebfa8 lr = 0xc04ee88c (ufs_direnter+0x45c) > sp = 0xdd6ff9b8 fp = 0xdd6ffa20 > r4 = 0xc2ab1e80 r5 = 0xcd3af84c > r6 = 0xdd6ffa48 r7 = 0x00000001 > r8 = 0x0000004c r9 = 0xc2c067e0 > ufs_direnter() at ufs_direnter+0x45c > pc = 0xc04ee88c lr = 0xc04f7e04 (ufs_makeinode+0x3f4) > sp = 0xdd6ffa28 fp = 0xdd6ffb88 > r4 = 0xdd6ffa48 r5 = 0xc2ab1180 > r6 = 0xdd6ffd48 r7 = 0x00000000 > r8 = 0xc2c067e0 r9 = 0xdd6ffd30 > r10 = 0x000081a4 > ufs_makeinode() at ufs_makeinode+0x3f4 > pc = 0xc04f7e04 lr = 0xc04f4268 (ufs_create+0x24) > sp = 0xdd6ffb90 fp = 0xdd6ffb90 > r4 = 0xdd6ffc60 r5 = 0xc064eba0 > r6 = 0x00000000 r7 = 0x00100a02 > r8 = 0x00000000 r9 = 0xdd6ffd30 > r10 = 0xdd6ffd50 > ufs_create() at ufs_create+0x24 > pc = 0xc04f4268 lr = 0xc0552268 (VOP_CREATE_APV+0xd0) > sp = 0xdd6ffb98 fp = 0xdd6ffba8 > VOP_CREATE_APV() at VOP_CREATE_APV+0xd0 > pc = 0xc0552268 lr = 0xc0408540 (vn_open_cred+0x278) > sp = 0xdd6ffbb0 fp = 0xdd6ffc90 > r4 = 0xdd6ffce0 r5 = 0xdd6ffd30 > r6 = 0xc2c067e0 > vn_open_cred() at vn_open_cred+0x278 > pc = 0xc0408540 lr = 0xc04082c0 (vn_open+0x24) > sp = 0xdd6ffc98 fp = 0xdd6ffca0 > r4 = 0xc2a2d640 r5 = 0xc2a76000 > r6 = 0xdd6ffce0 r7 = 0x00000012 > r8 = 0x00000000 r9 = 0x000500cf > r10 = 0xdd6ffcd0 > vn_open() at vn_open+0x24 > pc = 0xc04082c0 lr = 0xc040187c (kern_openat+0x24c) > sp = 0xdd6ffca8 fp = 0xdd6ffda8 > kern_openat() at kern_openat+0x24c > pc = 0xc040187c lr = 0xc04015c4 (sys_open+0x28) > sp = 0xdd6ffdb0 fp = 0xdd6ffdb8 > r4 = 0xc2a2d640 r5 = 0x00000000 > r6 = 0x20cc1198 r7 = 0x00000000 > r8 = 0xdd6ffe10 r9 = 0xc29f6c80 > r10 = 0x20c24080 > sys_open() at sys_open+0x28 > pc = 0xc04015c4 lr = 0xc0540764 (swi_handler+0x284) > sp = 0xdd6ffdc0 fp = 0xdd6ffe58 > swi_handler() at swi_handler+0x284 > pc = 0xc0540764 lr = 0xc0530350 (swi_entry+0x2c) > sp = 0xdd6ffe60 fp = 0xbfffe960 > r4 = 0x20c0a200 r5 = 0x000001a4 > r6 = 0x20cc1198 r7 = 0x00000005 > r8 = 0x20c0a200 r9 = 0x00000001 > swi_entry() at swi_entry+0x2c > pc = 0xc0530350 lr = 0xc0530350 (swi_entry+0x2c) > sp = 0xdd6ffe60 fp = 0xbfffe960 > Unable to unwind further > lock order reversal: > 1st 0xc2c06814 ufs (ufs) @ > /root/crochet-freebsd/src/sys/kern/vfs_subr.c:2099 > 2nd 0xcd1299d0 bufwait (bufwait) @ > /root/crochet-freebsd/src/sys/ufs/ffs/ffs_vnops.c:262 > 3rd 0xc2cb9154 ufs (ufs) @ > /root/crochet-freebsd/src/sys/kern/vfs_subr.c:2099 > KDB: stack backtrace: > db_trace_self() at db_trace_self > pc = 0xc052ecf4 lr = 0xc022dcd0 (db_trace_self_wrapper+0x30) > sp = 0xdd6ff578 fp = 0xdd6ff690 > r10 = 0xc05adb30 > db_trace_self_wrapper() at db_trace_self_wrapper+0x30 > pc = 0xc022dcd0 lr = 0xc038e9e0 (kdb_backtrace+0x38) > sp = 0xdd6ff698 fp = 0xdd6ff6a0 > r4 = 0xc066a484 r5 = 0xc0592f71 > r6 = 0xc059b3d0 r7 = 0xc05adb33 > kdb_backtrace() at kdb_backtrace+0x38 > pc = 0xc038e9e0 lr = 0xc03a8b5c (witness_checkorder+0xda0) > sp = 0xdd6ff6a8 fp = 0xdd6ff6f8 > r4 = 0xc0581d1c > witness_checkorder() at witness_checkorder+0xda0 > pc = 0xc03a8b5c lr = 0xc033c5fc (__lockmgr_args+0x698) > sp = 0xdd6ff700 fp = 0xdd6ff768 > r4 = 0x00080100 r5 = 0x00000833 > r6 = 0xc2cb9154 r7 = 0x00080000 > r8 = 0x00000100 r9 = 0x00000000 > r10 = 0xc059b3cd > __lockmgr_args() at __lockmgr_args+0x698 > pc = 0xc033c5fc lr = 0xc04e678c (ffs_lock+0x80) > sp = 0xdd6ff770 fp = 0xdd6ff798 > r4 = 0xdd6ff7b8 r5 = 0x00080100 > r6 = 0xc2cb9120 r7 = 0xc2cb9154 > r8 = 0xc2cb9174 r9 = 0x00000000 > r10 = 0xc059b3cd > ffs_lock() at ffs_lock+0x80 > pc = 0xc04e678c lr = 0xc0554118 (VOP_LOCK1_APV+0xd8) > sp = 0xdd6ff7a0 fp = 0xdd6ff7b0 > r4 = 0xdd6ff7b8 r5 = 0xc064e690 > r6 = 0x00000000 r7 = 0x00000000 > r8 = 0xc2a2d640 r9 = 0x00000833 > VOP_LOCK1_APV() at VOP_LOCK1_APV+0xd8 > pc = 0xc0554118 lr = 0xc0408cbc (_vn_lock+0x78) > sp = 0xdd6ff7b8 fp = 0xdd6ff7e8 > r4 = 0xc2cb9120 r5 = 0x00080100 > r6 = 0x00080100 > _vn_lock() at _vn_lock+0x78 > pc = 0xc0408cbc lr = 0xc03f97e8 (vget+0x60) > sp = 0xdd6ff7f0 fp = 0xdd6ff810 > r4 = 0xc2cb9120 r5 = 0x00000000 > r6 = 0x00080100 r7 = 0x00000000 > r8 = 0xc2a2d640 r9 = 0xc059a607 > r10 = 0x00000000 > vget() at vget+0x60 > pc = 0xc03f97e8 lr = 0xc03ede5c (vfs_hash_get+0xe4) > sp = 0xdd6ff818 fp = 0xdd6ff848 > r4 = 0xc2a0b2b0 r5 = 0x00000000 > r6 = 0x0002787d r7 = 0x00000000 > r8 = 0xc2cb9120 > vfs_hash_get() at vfs_hash_get+0xe4 > pc = 0xc03ede5c lr = 0xc04e17f4 (ffs_vgetf+0x3c) > sp = 0xdd6ff850 fp = 0xdd6ff8a0 > r4 = 0x0002787d r5 = 0xc05aa74b > r6 = 0xc2bb13c0 r7 = 0xdd6ff908 > r8 = 0xc2bb13c0 r9 = 0x00080000 > r10 = 0xc2a0b2b0 > ffs_vgetf() at ffs_vgetf+0x3c > pc = 0xc04e17f4 lr = 0xc04da468 (softdep_sync_buf+0x974) > sp = 0xdd6ff8a8 fp = 0xdd6ff928 > r4 = 0x0002787d r5 = 0xc05aa74b > r6 = 0xc2bb13c0 r7 = 0xc05aa74b > r8 = 0xc2bb13c0 r9 = 0x0000088b > r10 = 0x0002787d > softdep_sync_buf() at softdep_sync_buf+0x974 > pc = 0xc04da468 lr = 0xc04e7560 (ffs_syncvnode+0x2bc) > sp = 0xdd6ff930 fp = 0xdd6ff980 > r4 = 0x00000000 r5 = 0xcd188d48 > r6 = 0x00060200 r7 = 0xc2c067e0 > r8 = 0xc05adb30 r9 = 0xcd1299d0 > r10 = 0xcd129978 > ffs_syncvnode() at ffs_syncvnode+0x2bc > pc = 0xc04e7560 lr = 0xc04e6650 (ffs_fsync+0x20) > sp = 0xdd6ff988 fp = 0xdd6ff998 > r4 = 0xdd6ff9f0 r5 = 0xc2c067e0 > r6 = 0x00000000 r7 = 0x00000200 > r8 = 0xc2a2d640 r9 = 0xc2c067e0 > r10 = 0xc33445a0 > ffs_fsync() at ffs_fsync+0x20 > pc = 0xc04e6650 lr = 0xc05534b8 (VOP_FSYNC_APV+0xd0) > sp = 0xdd6ff9a0 fp = 0xdd6ff9b0 > r4 = 0xdd6ff9f0 r5 = 0xc064e690 > r6 = 0x00000000 r7 = 0x00000200 > VOP_FSYNC_APV() at VOP_FSYNC_APV+0xd0 > pc = 0xc05534b8 lr = 0xc04eeb54 (ufs_direnter+0x724) > sp = 0xdd6ff9b8 fp = 0xdd6ffa20 > r4 = 0xc33445a0 r5 = 0x00000000 > r6 = 0xcd356e00 > ufs_direnter() at ufs_direnter+0x724 > pc = 0xc04eeb54 lr = 0xc04f7e04 (ufs_makeinode+0x3f4) > sp = 0xdd6ffa28 fp = 0xdd6ffb88 > r4 = 0xdd6ffa48 r5 = 0xc332fa00 > r6 = 0xdd6ffd48 r7 = 0x00000000 > r8 = 0xc2c067e0 r9 = 0xdd6ffd30 > r10 = 0x000081a4 > ufs_makeinode() at ufs_makeinode+0x3f4 > pc = 0xc04f7e04 lr = 0xc04f4268 (ufs_create+0x24) > sp = 0xdd6ffb90 fp = 0xdd6ffb90 > r4 = 0xdd6ffc60 r5 = 0xc064eba0 > r6 = 0x00000000 r7 = 0x00100a02 > r8 = 0x00000000 r9 = 0xdd6ffd30 > r10 = 0xdd6ffd50 > ufs_create() at ufs_create+0x24 > pc = 0xc04f4268 lr = 0xc0552268 (VOP_CREATE_APV+0xd0) > sp = 0xdd6ffb98 fp = 0xdd6ffba8 > VOP_CREATE_APV() at VOP_CREATE_APV+0xd0 > pc = 0xc0552268 lr = 0xc0408540 (vn_open_cred+0x278) > sp = 0xdd6ffbb0 fp = 0xdd6ffc90 > r4 = 0xdd6ffce0 r5 = 0xdd6ffd30 > r6 = 0xc2c067e0 > vn_open_cred() at vn_open_cred+0x278 > pc = 0xc0408540 lr = 0xc04082c0 (vn_open+0x24) > sp = 0xdd6ffc98 fp = 0xdd6ffca0 > r4 = 0xc2a2d640 r5 = 0xc2a76000 > r6 = 0xdd6ffce0 r7 = 0x00000012 > r8 = 0x00000000 r9 = 0x000500cf > r10 = 0xdd6ffcd0 > vn_open() at vn_open+0x24 > pc = 0xc04082c0 lr = 0xc040187c (kern_openat+0x24c) > sp = 0xdd6ffca8 fp = 0xdd6ffda8 > kern_openat() at kern_openat+0x24c > pc = 0xc040187c lr = 0xc04015c4 (sys_open+0x28) > sp = 0xdd6ffdb0 fp = 0xdd6ffdb8 > r4 = 0xc2a2d640 r5 = 0x00000000 > r6 = 0x20cc1198 r7 = 0x00000000 > r8 = 0xdd6ffe10 r9 = 0xc29f6c80 > r10 = 0x20c24080 > sys_open() at sys_open+0x28 > pc = 0xc04015c4 lr = 0xc0540764 (swi_handler+0x284) > sp = 0xdd6ffdc0 fp = 0xdd6ffe58 > swi_handler() at swi_handler+0x284 > pc = 0xc0540764 lr = 0xc0530350 (swi_entry+0x2c) > sp = 0xdd6ffe60 fp = 0xbfffe960 > r4 = 0x20c0a200 r5 = 0x000001a4 > r6 = 0x20cc1198 r7 = 0x00000 > _______________________________________________ > 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 Sep 21 09:53:33 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 9A4E44D5 for ; Sat, 21 Sep 2013 09:53:33 +0000 (UTC) (envelope-from david.cheney@canonical.com) Received: from mail-la0-f41.google.com (mail-la0-f41.google.com [209.85.215.41]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 0E4DE250B for ; Sat, 21 Sep 2013 09:53:32 +0000 (UTC) Received: by mail-la0-f41.google.com with SMTP id ec20so1142642lab.0 for ; Sat, 21 Sep 2013 02:53:25 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=MiUCJ0MAJhQlMr1eprnWFrSrUlcFUT+yk1ONt1Mq5QE=; b=OnjLS7bELt8RCKMAdkL9ffApv2NfZ+CqtHz94gAAcjAwDfJg3WvXdFOTJPvqBs1/88 qJ6LoSusDR5RkYrOUP8l1mIedFq+LY4tDghejKknnOtMnNlYpIpymVHoa68obR7J2dw0 kqsKwUj50Xd5pJYBYs+fZMowLtCcK3ZoM0VrX/8qmg5++qPX183DL0FbOIJ4wlMcTI6+ FY5U+xYYfXYMfEk95Reiop6ikVZSwkFB65S+OPly9gg1OUi2+4uHw69mky/yHnrE/z4f Q55iywl6iYS/vtBN6vDqSeFqkzxw51gTI+lAWI+4sJc6iXU4DHOBo9FiswqfuLG1us2o lL2g== X-Gm-Message-State: ALoCoQlPfz3hOQ/4vjBAEIPgxV8VhYkWWYllvc0rtz+laX4omUksxXvtDvxHJyFq4X7ONJ3+Xupt MIME-Version: 1.0 X-Received: by 10.112.89.100 with SMTP id bn4mr10214979lbb.16.1379757205258; Sat, 21 Sep 2013 02:53:25 -0700 (PDT) Received: by 10.114.183.47 with HTTP; Sat, 21 Sep 2013 02:53:25 -0700 (PDT) In-Reply-To: References: Date: Sat, 21 Sep 2013 19:53:25 +1000 Message-ID: Subject: Re: freebsd on beaglebone black, lock reversal panic shortly after first boot From: David Cheney To: Ronald Klop Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Sep 2013 09:53:33 -0000 Ronald, Thanks for your reply. I'm sorry, I am inexperienced with this sort of thing, the machine has not crash, in fact it still building a port now. From my linux background, if I saw that much output, the host would be kerput. Cheers Dave On Sat, Sep 21, 2013 at 7:46 PM, Ronald Klop wrote: > On Sat, 21 Sep 2013 00:45:48 +0200, David Cheney > wrote: > >> Hello, >> >> I've been trying to replace my old RPi freebsd system, which I haven't >> been able to get a working build for months on, with a Beaglebone >> Black. This was the message I received after booting the card for the >> first time and trying to portsnap. >> >> Cheers >> >> Dave > > > In the subject you mention it is a panic, but that does not show from the > output. > Is your machine hanging? Or does it reboot after the panic? Or can you just > work on. > There are a lot of lock order reversals (LORs) which are harmless for the > working of the machine. I don't know about this one. > > Ronald. > >> >> --- >> >> >> FreeBSD/arm (beaglebone) (ttyu0) >> >> login: root >> Sep 20 21:57:34 beaglebone login: ROOT LOGIN (root) ON ttyu0 >> FreeBSD 10.0-ALPHA2 (BEAGLEBONE) #0 r255662: Fri Sep 20 23:04:55 EST 2013 >> >> Welcome to FreeBSD! >> >> Before seeking technical support, please use the following resources: >> >> o Security advisories and updated errata information for all releases are >> at http://www.FreeBSD.org/releases/ - always consult the ERRATA section >> for your release first as it's updated frequently. >> >> o The Handbook and FAQ documents are at http://www.FreeBSD.org/ and, >> along with the mailing lists, can be searched by going to >> http://www.FreeBSD.org/search/. If the doc package has been installed >> (or fetched via pkg install lang-freebsd-doc, where lang is the >> 2-letter language code, e.g. en), they are also available formatted >> in /usr/local/share/doc/freebsd. >> >> If you still have a question or problem, please take the output of >> `uname -a', along with any relevant error messages, and email it >> as a question to the questions@FreeBSD.org mailing list. If you are >> unfamiliar with FreeBSD's directory layout, please refer to the hier(7) >> manual page. If you are not familiar with manual pages, type `man man'. >> >> Edit /etc/motd to change this login announcement. >> >> root@beaglebone:~ # df -h >> Filesystem Size Used Avail Capacity Mounted on >> /dev/mmcsd0s2a 3.5G 396M 2.9G 12% / >> devfs 1.0k 1.0k 0B 100% /dev >> /dev/mmcsd0s1 2M 693k 1.3M 34% /boot/msdos >> /dev/md0 28M 24k 26M 0% /tmp >> /dev/md1 14M 60k 13M 0% /var/log >> /dev/md2 4.4M 8.0k 4.0M 0% /var/tmp >> root@beaglebone:~ # portsnap fetch && portsnap extract >> Looking up portsnap.FreeBSD.org mirrors... 7 mirrors found. >> Fetching public key from ec2-ap-southeast-2.portsnap.freebsd.org... done. >> Fetching snapshot tag from ec2-ap-southeast-2.portsnap.freebsd.org... >> done. >> Fetching snapshot metadata... done. >> Fetching snapshot generated at Fri Sep 20 00:08:00 UTC 2013: >> f88e945869b296b518253a080d33b8c988a382fd82586c100% of 69 MB 1473 kBps >> 00m48s >> Extracting snapshot... lock order reversal: >> 1st 0xcd1299d0 bufwait (bufwait) @ >> /root/crochet-freebsd/src/sys/kern/vfs_bio.c:3059 >> 2nd 0xc2a8f600 dirhash (dirhash) @ >> /root/crochet-freebsd/src/sys/ufs/ufs/ufs_dirhash.c:284 >> KDB: stack backtrace: >> db_trace_self() at db_trace_self >> pc = 0xc052ecf4 lr = 0xc022dcd0 (db_trace_self_wrapper+0x30) >> sp = 0xdd6ff7e0 fp = 0xdd6ff8f8 >> r10 = 0xcd1299d0 >> db_trace_self_wrapper() at db_trace_self_wrapper+0x30 >> pc = 0xc022dcd0 lr = 0xc038e9e0 (kdb_backtrace+0x38) >> sp = 0xdd6ff900 fp = 0xdd6ff908 >> r4 = 0xc066a484 r5 = 0xc05ae078 >> r6 = 0xc0592f71 r7 = 0xc0598518 >> kdb_backtrace() at kdb_backtrace+0x38 >> pc = 0xc038e9e0 lr = 0xc03a8b5c (witness_checkorder+0xda0) >> sp = 0xdd6ff910 fp = 0xdd6ff960 >> r4 = 0xc05ae43b >> witness_checkorder() at witness_checkorder+0xda0 >> pc = 0xc03a8b5c lr = 0xc035ff8c (_sx_xlock+0x84) >> sp = 0xdd6ff968 fp = 0xdd6ff990 >> r4 = 0x0000011c r5 = 0xc05ae075 >> r6 = 0xc2a8f610 r7 = 0xc2a8f600 >> r8 = 0x00000000 r9 = 0xc2c067e0 >> r10 = 0x000001b4 >> _sx_xlock() at _sx_xlock+0x84 >> pc = 0xc035ff8c lr = 0xc04ebfa8 (ufsdirhash_add+0x34) >> sp = 0xdd6ff998 fp = 0xdd6ff9b0 >> r4 = 0xc2a8f600 r5 = 0xc2ab1e80 >> r6 = 0xdd6ffa48 r7 = 0x00000001 >> r8 = 0x0000084c >> ufsdirhash_add() at ufsdirhash_add+0x34 >> pc = 0xc04ebfa8 lr = 0xc04ee88c (ufs_direnter+0x45c) >> sp = 0xdd6ff9b8 fp = 0xdd6ffa20 >> r4 = 0xc2ab1e80 r5 = 0xcd3af84c >> r6 = 0xdd6ffa48 r7 = 0x00000001 >> r8 = 0x0000004c r9 = 0xc2c067e0 >> ufs_direnter() at ufs_direnter+0x45c >> pc = 0xc04ee88c lr = 0xc04f7e04 (ufs_makeinode+0x3f4) >> sp = 0xdd6ffa28 fp = 0xdd6ffb88 >> r4 = 0xdd6ffa48 r5 = 0xc2ab1180 >> r6 = 0xdd6ffd48 r7 = 0x00000000 >> r8 = 0xc2c067e0 r9 = 0xdd6ffd30 >> r10 = 0x000081a4 >> ufs_makeinode() at ufs_makeinode+0x3f4 >> pc = 0xc04f7e04 lr = 0xc04f4268 (ufs_create+0x24) >> sp = 0xdd6ffb90 fp = 0xdd6ffb90 >> r4 = 0xdd6ffc60 r5 = 0xc064eba0 >> r6 = 0x00000000 r7 = 0x00100a02 >> r8 = 0x00000000 r9 = 0xdd6ffd30 >> r10 = 0xdd6ffd50 >> ufs_create() at ufs_create+0x24 >> pc = 0xc04f4268 lr = 0xc0552268 (VOP_CREATE_APV+0xd0) >> sp = 0xdd6ffb98 fp = 0xdd6ffba8 >> VOP_CREATE_APV() at VOP_CREATE_APV+0xd0 >> pc = 0xc0552268 lr = 0xc0408540 (vn_open_cred+0x278) >> sp = 0xdd6ffbb0 fp = 0xdd6ffc90 >> r4 = 0xdd6ffce0 r5 = 0xdd6ffd30 >> r6 = 0xc2c067e0 >> vn_open_cred() at vn_open_cred+0x278 >> pc = 0xc0408540 lr = 0xc04082c0 (vn_open+0x24) >> sp = 0xdd6ffc98 fp = 0xdd6ffca0 >> r4 = 0xc2a2d640 r5 = 0xc2a76000 >> r6 = 0xdd6ffce0 r7 = 0x00000012 >> r8 = 0x00000000 r9 = 0x000500cf >> r10 = 0xdd6ffcd0 >> vn_open() at vn_open+0x24 >> pc = 0xc04082c0 lr = 0xc040187c (kern_openat+0x24c) >> sp = 0xdd6ffca8 fp = 0xdd6ffda8 >> kern_openat() at kern_openat+0x24c >> pc = 0xc040187c lr = 0xc04015c4 (sys_open+0x28) >> sp = 0xdd6ffdb0 fp = 0xdd6ffdb8 >> r4 = 0xc2a2d640 r5 = 0x00000000 >> r6 = 0x20cc1198 r7 = 0x00000000 >> r8 = 0xdd6ffe10 r9 = 0xc29f6c80 >> r10 = 0x20c24080 >> sys_open() at sys_open+0x28 >> pc = 0xc04015c4 lr = 0xc0540764 (swi_handler+0x284) >> sp = 0xdd6ffdc0 fp = 0xdd6ffe58 >> swi_handler() at swi_handler+0x284 >> pc = 0xc0540764 lr = 0xc0530350 (swi_entry+0x2c) >> sp = 0xdd6ffe60 fp = 0xbfffe960 >> r4 = 0x20c0a200 r5 = 0x000001a4 >> r6 = 0x20cc1198 r7 = 0x00000005 >> r8 = 0x20c0a200 r9 = 0x00000001 >> swi_entry() at swi_entry+0x2c >> pc = 0xc0530350 lr = 0xc0530350 (swi_entry+0x2c) >> sp = 0xdd6ffe60 fp = 0xbfffe960 >> Unable to unwind further >> lock order reversal: >> 1st 0xc2c06814 ufs (ufs) @ >> /root/crochet-freebsd/src/sys/kern/vfs_subr.c:2099 >> 2nd 0xcd1299d0 bufwait (bufwait) @ >> /root/crochet-freebsd/src/sys/ufs/ffs/ffs_vnops.c:262 >> 3rd 0xc2cb9154 ufs (ufs) @ >> /root/crochet-freebsd/src/sys/kern/vfs_subr.c:2099 >> KDB: stack backtrace: >> db_trace_self() at db_trace_self >> pc = 0xc052ecf4 lr = 0xc022dcd0 (db_trace_self_wrapper+0x30) >> sp = 0xdd6ff578 fp = 0xdd6ff690 >> r10 = 0xc05adb30 >> db_trace_self_wrapper() at db_trace_self_wrapper+0x30 >> pc = 0xc022dcd0 lr = 0xc038e9e0 (kdb_backtrace+0x38) >> sp = 0xdd6ff698 fp = 0xdd6ff6a0 >> r4 = 0xc066a484 r5 = 0xc0592f71 >> r6 = 0xc059b3d0 r7 = 0xc05adb33 >> kdb_backtrace() at kdb_backtrace+0x38 >> pc = 0xc038e9e0 lr = 0xc03a8b5c (witness_checkorder+0xda0) >> sp = 0xdd6ff6a8 fp = 0xdd6ff6f8 >> r4 = 0xc0581d1c >> witness_checkorder() at witness_checkorder+0xda0 >> pc = 0xc03a8b5c lr = 0xc033c5fc (__lockmgr_args+0x698) >> sp = 0xdd6ff700 fp = 0xdd6ff768 >> r4 = 0x00080100 r5 = 0x00000833 >> r6 = 0xc2cb9154 r7 = 0x00080000 >> r8 = 0x00000100 r9 = 0x00000000 >> r10 = 0xc059b3cd >> __lockmgr_args() at __lockmgr_args+0x698 >> pc = 0xc033c5fc lr = 0xc04e678c (ffs_lock+0x80) >> sp = 0xdd6ff770 fp = 0xdd6ff798 >> r4 = 0xdd6ff7b8 r5 = 0x00080100 >> r6 = 0xc2cb9120 r7 = 0xc2cb9154 >> r8 = 0xc2cb9174 r9 = 0x00000000 >> r10 = 0xc059b3cd >> ffs_lock() at ffs_lock+0x80 >> pc = 0xc04e678c lr = 0xc0554118 (VOP_LOCK1_APV+0xd8) >> sp = 0xdd6ff7a0 fp = 0xdd6ff7b0 >> r4 = 0xdd6ff7b8 r5 = 0xc064e690 >> r6 = 0x00000000 r7 = 0x00000000 >> r8 = 0xc2a2d640 r9 = 0x00000833 >> VOP_LOCK1_APV() at VOP_LOCK1_APV+0xd8 >> pc = 0xc0554118 lr = 0xc0408cbc (_vn_lock+0x78) >> sp = 0xdd6ff7b8 fp = 0xdd6ff7e8 >> r4 = 0xc2cb9120 r5 = 0x00080100 >> r6 = 0x00080100 >> _vn_lock() at _vn_lock+0x78 >> pc = 0xc0408cbc lr = 0xc03f97e8 (vget+0x60) >> sp = 0xdd6ff7f0 fp = 0xdd6ff810 >> r4 = 0xc2cb9120 r5 = 0x00000000 >> r6 = 0x00080100 r7 = 0x00000000 >> r8 = 0xc2a2d640 r9 = 0xc059a607 >> r10 = 0x00000000 >> vget() at vget+0x60 >> pc = 0xc03f97e8 lr = 0xc03ede5c (vfs_hash_get+0xe4) >> sp = 0xdd6ff818 fp = 0xdd6ff848 >> r4 = 0xc2a0b2b0 r5 = 0x00000000 >> r6 = 0x0002787d r7 = 0x00000000 >> r8 = 0xc2cb9120 >> vfs_hash_get() at vfs_hash_get+0xe4 >> pc = 0xc03ede5c lr = 0xc04e17f4 (ffs_vgetf+0x3c) >> sp = 0xdd6ff850 fp = 0xdd6ff8a0 >> r4 = 0x0002787d r5 = 0xc05aa74b >> r6 = 0xc2bb13c0 r7 = 0xdd6ff908 >> r8 = 0xc2bb13c0 r9 = 0x00080000 >> r10 = 0xc2a0b2b0 >> ffs_vgetf() at ffs_vgetf+0x3c >> pc = 0xc04e17f4 lr = 0xc04da468 (softdep_sync_buf+0x974) >> sp = 0xdd6ff8a8 fp = 0xdd6ff928 >> r4 = 0x0002787d r5 = 0xc05aa74b >> r6 = 0xc2bb13c0 r7 = 0xc05aa74b >> r8 = 0xc2bb13c0 r9 = 0x0000088b >> r10 = 0x0002787d >> softdep_sync_buf() at softdep_sync_buf+0x974 >> pc = 0xc04da468 lr = 0xc04e7560 (ffs_syncvnode+0x2bc) >> sp = 0xdd6ff930 fp = 0xdd6ff980 >> r4 = 0x00000000 r5 = 0xcd188d48 >> r6 = 0x00060200 r7 = 0xc2c067e0 >> r8 = 0xc05adb30 r9 = 0xcd1299d0 >> r10 = 0xcd129978 >> ffs_syncvnode() at ffs_syncvnode+0x2bc >> pc = 0xc04e7560 lr = 0xc04e6650 (ffs_fsync+0x20) >> sp = 0xdd6ff988 fp = 0xdd6ff998 >> r4 = 0xdd6ff9f0 r5 = 0xc2c067e0 >> r6 = 0x00000000 r7 = 0x00000200 >> r8 = 0xc2a2d640 r9 = 0xc2c067e0 >> r10 = 0xc33445a0 >> ffs_fsync() at ffs_fsync+0x20 >> pc = 0xc04e6650 lr = 0xc05534b8 (VOP_FSYNC_APV+0xd0) >> sp = 0xdd6ff9a0 fp = 0xdd6ff9b0 >> r4 = 0xdd6ff9f0 r5 = 0xc064e690 >> r6 = 0x00000000 r7 = 0x00000200 >> VOP_FSYNC_APV() at VOP_FSYNC_APV+0xd0 >> pc = 0xc05534b8 lr = 0xc04eeb54 (ufs_direnter+0x724) >> sp = 0xdd6ff9b8 fp = 0xdd6ffa20 >> r4 = 0xc33445a0 r5 = 0x00000000 >> r6 = 0xcd356e00 >> ufs_direnter() at ufs_direnter+0x724 >> pc = 0xc04eeb54 lr = 0xc04f7e04 (ufs_makeinode+0x3f4) >> sp = 0xdd6ffa28 fp = 0xdd6ffb88 >> r4 = 0xdd6ffa48 r5 = 0xc332fa00 >> r6 = 0xdd6ffd48 r7 = 0x00000000 >> r8 = 0xc2c067e0 r9 = 0xdd6ffd30 >> r10 = 0x000081a4 >> ufs_makeinode() at ufs_makeinode+0x3f4 >> pc = 0xc04f7e04 lr = 0xc04f4268 (ufs_create+0x24) >> sp = 0xdd6ffb90 fp = 0xdd6ffb90 >> r4 = 0xdd6ffc60 r5 = 0xc064eba0 >> r6 = 0x00000000 r7 = 0x00100a02 >> r8 = 0x00000000 r9 = 0xdd6ffd30 >> r10 = 0xdd6ffd50 >> ufs_create() at ufs_create+0x24 >> pc = 0xc04f4268 lr = 0xc0552268 (VOP_CREATE_APV+0xd0) >> sp = 0xdd6ffb98 fp = 0xdd6ffba8 >> VOP_CREATE_APV() at VOP_CREATE_APV+0xd0 >> pc = 0xc0552268 lr = 0xc0408540 (vn_open_cred+0x278) >> sp = 0xdd6ffbb0 fp = 0xdd6ffc90 >> r4 = 0xdd6ffce0 r5 = 0xdd6ffd30 >> r6 = 0xc2c067e0 >> vn_open_cred() at vn_open_cred+0x278 >> pc = 0xc0408540 lr = 0xc04082c0 (vn_open+0x24) >> sp = 0xdd6ffc98 fp = 0xdd6ffca0 >> r4 = 0xc2a2d640 r5 = 0xc2a76000 >> r6 = 0xdd6ffce0 r7 = 0x00000012 >> r8 = 0x00000000 r9 = 0x000500cf >> r10 = 0xdd6ffcd0 >> vn_open() at vn_open+0x24 >> pc = 0xc04082c0 lr = 0xc040187c (kern_openat+0x24c) >> sp = 0xdd6ffca8 fp = 0xdd6ffda8 >> kern_openat() at kern_openat+0x24c >> pc = 0xc040187c lr = 0xc04015c4 (sys_open+0x28) >> sp = 0xdd6ffdb0 fp = 0xdd6ffdb8 >> r4 = 0xc2a2d640 r5 = 0x00000000 >> r6 = 0x20cc1198 r7 = 0x00000000 >> r8 = 0xdd6ffe10 r9 = 0xc29f6c80 >> r10 = 0x20c24080 >> sys_open() at sys_open+0x28 >> pc = 0xc04015c4 lr = 0xc0540764 (swi_handler+0x284) >> sp = 0xdd6ffdc0 fp = 0xdd6ffe58 >> swi_handler() at swi_handler+0x284 >> pc = 0xc0540764 lr = 0xc0530350 (swi_entry+0x2c) >> sp = 0xdd6ffe60 fp = 0xbfffe960 >> r4 = 0x20c0a200 r5 = 0x000001a4 >> r6 = 0x20cc1198 r7 = 0x00000 >> _______________________________________________ >> 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 Sat Sep 21 12:08:43 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id CCA8F1E8 for ; Sat, 21 Sep 2013 12:08:43 +0000 (UTC) (envelope-from rrs@lakerest.net) Received: from lakerest.net (lakerest.net [70.155.160.98]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id DBD892BF2 for ; Sat, 21 Sep 2013 12:08:42 +0000 (UTC) Received: from [10.1.1.103] (bsd4.lakerest.net [70.155.160.102]) (authenticated bits=0) by lakerest.net (8.14.4/8.14.3) with ESMTP id r8LC8bHD081753 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sat, 21 Sep 2013 08:08:38 -0400 (EDT) (envelope-from rrs@lakerest.net) Subject: Re: freebsd on beaglebone black, lock reversal panic shortly after first boot Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Randall Stewart In-Reply-To: Date: Sat, 21 Sep 2013 08:08:37 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: David Cheney X-Mailer: Apple Mail (2.1283) Cc: freebsd-arm@freebsd.org, Ronald Klop X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Sep 2013 12:08:43 -0000 David: I believe you are seeing a reported Lock Order Reversal since you are running with a WITNESS kernel. This particular one I recognize and see on other platforms as well. Its one of those ones that has never been either fixed or marked as "blessed". If you want to get rid of these (and increase performance) go in to your kernel configuration and comment out the two lines that mention "option = WITNESS*" (just put a # in front of them). That will disable witness and speed up the kernel ;-) Of course if you are doing kernel debugging you probably want WITNESS on = since it does give lots of good information.. that particular one is just one we = have to ignore ;-D Best wishes R On Sep 21, 2013, at 5:53 AM, David Cheney wrote: > Ronald, >=20 > Thanks for your reply. I'm sorry, I am inexperienced with this sort of > thing, the machine has not crash, in fact it still building a port > now. =46rom my linux background, if I saw that much output, the host > would be kerput. >=20 > Cheers >=20 > Dave >=20 >=20 > On Sat, Sep 21, 2013 at 7:46 PM, Ronald Klop > wrote: >> On Sat, 21 Sep 2013 00:45:48 +0200, David Cheney >> wrote: >>=20 >>> Hello, >>>=20 >>> I've been trying to replace my old RPi freebsd system, which I = haven't >>> been able to get a working build for months on, with a Beaglebone >>> Black. This was the message I received after booting the card for = the >>> first time and trying to portsnap. >>>=20 >>> Cheers >>>=20 >>> Dave >>=20 >>=20 >> In the subject you mention it is a panic, but that does not show from = the >> output. >> Is your machine hanging? Or does it reboot after the panic? Or can = you just >> work on. >> There are a lot of lock order reversals (LORs) which are harmless for = the >> working of the machine. I don't know about this one. >>=20 >> Ronald. >>=20 >>>=20 >>> --- >>>=20 >>>=20 >>> FreeBSD/arm (beaglebone) (ttyu0) >>>=20 >>> login: root >>> Sep 20 21:57:34 beaglebone login: ROOT LOGIN (root) ON ttyu0 >>> FreeBSD 10.0-ALPHA2 (BEAGLEBONE) #0 r255662: Fri Sep 20 23:04:55 EST = 2013 >>>=20 >>> Welcome to FreeBSD! >>>=20 >>> Before seeking technical support, please use the following = resources: >>>=20 >>> o Security advisories and updated errata information for all = releases are >>> at http://www.FreeBSD.org/releases/ - always consult the ERRATA = section >>> for your release first as it's updated frequently. >>>=20 >>> o The Handbook and FAQ documents are at http://www.FreeBSD.org/ = and, >>> along with the mailing lists, can be searched by going to >>> http://www.FreeBSD.org/search/. If the doc package has been = installed >>> (or fetched via pkg install lang-freebsd-doc, where lang is the >>> 2-letter language code, e.g. en), they are also available = formatted >>> in /usr/local/share/doc/freebsd. >>>=20 >>> If you still have a question or problem, please take the output of >>> `uname -a', along with any relevant error messages, and email it >>> as a question to the questions@FreeBSD.org mailing list. If you are >>> unfamiliar with FreeBSD's directory layout, please refer to the = hier(7) >>> manual page. If you are not familiar with manual pages, type `man = man'. >>>=20 >>> Edit /etc/motd to change this login announcement. >>>=20 >>> root@beaglebone:~ # df -h >>> Filesystem Size Used Avail Capacity Mounted on >>> /dev/mmcsd0s2a 3.5G 396M 2.9G 12% / >>> devfs 1.0k 1.0k 0B 100% /dev >>> /dev/mmcsd0s1 2M 693k 1.3M 34% /boot/msdos >>> /dev/md0 28M 24k 26M 0% /tmp >>> /dev/md1 14M 60k 13M 0% /var/log >>> /dev/md2 4.4M 8.0k 4.0M 0% /var/tmp >>> root@beaglebone:~ # portsnap fetch && portsnap extract >>> Looking up portsnap.FreeBSD.org mirrors... 7 mirrors found. >>> Fetching public key from ec2-ap-southeast-2.portsnap.freebsd.org... = done. >>> Fetching snapshot tag from = ec2-ap-southeast-2.portsnap.freebsd.org... >>> done. >>> Fetching snapshot metadata... done. >>> Fetching snapshot generated at Fri Sep 20 00:08:00 UTC 2013: >>> f88e945869b296b518253a080d33b8c988a382fd82586c100% of 69 MB 1473 = kBps >>> 00m48s >>> Extracting snapshot... lock order reversal: >>> 1st 0xcd1299d0 bufwait (bufwait) @ >>> /root/crochet-freebsd/src/sys/kern/vfs_bio.c:3059 >>> 2nd 0xc2a8f600 dirhash (dirhash) @ >>> /root/crochet-freebsd/src/sys/ufs/ufs/ufs_dirhash.c:284 >>> KDB: stack backtrace: >>> db_trace_self() at db_trace_self >>> pc =3D 0xc052ecf4 lr =3D 0xc022dcd0 = (db_trace_self_wrapper+0x30) >>> sp =3D 0xdd6ff7e0 fp =3D 0xdd6ff8f8 >>> r10 =3D 0xcd1299d0 >>> db_trace_self_wrapper() at db_trace_self_wrapper+0x30 >>> pc =3D 0xc022dcd0 lr =3D 0xc038e9e0 (kdb_backtrace+0x38) >>> sp =3D 0xdd6ff900 fp =3D 0xdd6ff908 >>> r4 =3D 0xc066a484 r5 =3D 0xc05ae078 >>> r6 =3D 0xc0592f71 r7 =3D 0xc0598518 >>> kdb_backtrace() at kdb_backtrace+0x38 >>> pc =3D 0xc038e9e0 lr =3D 0xc03a8b5c = (witness_checkorder+0xda0) >>> sp =3D 0xdd6ff910 fp =3D 0xdd6ff960 >>> r4 =3D 0xc05ae43b >>> witness_checkorder() at witness_checkorder+0xda0 >>> pc =3D 0xc03a8b5c lr =3D 0xc035ff8c (_sx_xlock+0x84) >>> sp =3D 0xdd6ff968 fp =3D 0xdd6ff990 >>> r4 =3D 0x0000011c r5 =3D 0xc05ae075 >>> r6 =3D 0xc2a8f610 r7 =3D 0xc2a8f600 >>> r8 =3D 0x00000000 r9 =3D 0xc2c067e0 >>> r10 =3D 0x000001b4 >>> _sx_xlock() at _sx_xlock+0x84 >>> pc =3D 0xc035ff8c lr =3D 0xc04ebfa8 (ufsdirhash_add+0x34) >>> sp =3D 0xdd6ff998 fp =3D 0xdd6ff9b0 >>> r4 =3D 0xc2a8f600 r5 =3D 0xc2ab1e80 >>> r6 =3D 0xdd6ffa48 r7 =3D 0x00000001 >>> r8 =3D 0x0000084c >>> ufsdirhash_add() at ufsdirhash_add+0x34 >>> pc =3D 0xc04ebfa8 lr =3D 0xc04ee88c (ufs_direnter+0x45c) >>> sp =3D 0xdd6ff9b8 fp =3D 0xdd6ffa20 >>> r4 =3D 0xc2ab1e80 r5 =3D 0xcd3af84c >>> r6 =3D 0xdd6ffa48 r7 =3D 0x00000001 >>> r8 =3D 0x0000004c r9 =3D 0xc2c067e0 >>> ufs_direnter() at ufs_direnter+0x45c >>> pc =3D 0xc04ee88c lr =3D 0xc04f7e04 (ufs_makeinode+0x3f4) >>> sp =3D 0xdd6ffa28 fp =3D 0xdd6ffb88 >>> r4 =3D 0xdd6ffa48 r5 =3D 0xc2ab1180 >>> r6 =3D 0xdd6ffd48 r7 =3D 0x00000000 >>> r8 =3D 0xc2c067e0 r9 =3D 0xdd6ffd30 >>> r10 =3D 0x000081a4 >>> ufs_makeinode() at ufs_makeinode+0x3f4 >>> pc =3D 0xc04f7e04 lr =3D 0xc04f4268 (ufs_create+0x24) >>> sp =3D 0xdd6ffb90 fp =3D 0xdd6ffb90 >>> r4 =3D 0xdd6ffc60 r5 =3D 0xc064eba0 >>> r6 =3D 0x00000000 r7 =3D 0x00100a02 >>> r8 =3D 0x00000000 r9 =3D 0xdd6ffd30 >>> r10 =3D 0xdd6ffd50 >>> ufs_create() at ufs_create+0x24 >>> pc =3D 0xc04f4268 lr =3D 0xc0552268 (VOP_CREATE_APV+0xd0) >>> sp =3D 0xdd6ffb98 fp =3D 0xdd6ffba8 >>> VOP_CREATE_APV() at VOP_CREATE_APV+0xd0 >>> pc =3D 0xc0552268 lr =3D 0xc0408540 (vn_open_cred+0x278) >>> sp =3D 0xdd6ffbb0 fp =3D 0xdd6ffc90 >>> r4 =3D 0xdd6ffce0 r5 =3D 0xdd6ffd30 >>> r6 =3D 0xc2c067e0 >>> vn_open_cred() at vn_open_cred+0x278 >>> pc =3D 0xc0408540 lr =3D 0xc04082c0 (vn_open+0x24) >>> sp =3D 0xdd6ffc98 fp =3D 0xdd6ffca0 >>> r4 =3D 0xc2a2d640 r5 =3D 0xc2a76000 >>> r6 =3D 0xdd6ffce0 r7 =3D 0x00000012 >>> r8 =3D 0x00000000 r9 =3D 0x000500cf >>> r10 =3D 0xdd6ffcd0 >>> vn_open() at vn_open+0x24 >>> pc =3D 0xc04082c0 lr =3D 0xc040187c (kern_openat+0x24c) >>> sp =3D 0xdd6ffca8 fp =3D 0xdd6ffda8 >>> kern_openat() at kern_openat+0x24c >>> pc =3D 0xc040187c lr =3D 0xc04015c4 (sys_open+0x28) >>> sp =3D 0xdd6ffdb0 fp =3D 0xdd6ffdb8 >>> r4 =3D 0xc2a2d640 r5 =3D 0x00000000 >>> r6 =3D 0x20cc1198 r7 =3D 0x00000000 >>> r8 =3D 0xdd6ffe10 r9 =3D 0xc29f6c80 >>> r10 =3D 0x20c24080 >>> sys_open() at sys_open+0x28 >>> pc =3D 0xc04015c4 lr =3D 0xc0540764 (swi_handler+0x284) >>> sp =3D 0xdd6ffdc0 fp =3D 0xdd6ffe58 >>> swi_handler() at swi_handler+0x284 >>> pc =3D 0xc0540764 lr =3D 0xc0530350 (swi_entry+0x2c) >>> sp =3D 0xdd6ffe60 fp =3D 0xbfffe960 >>> r4 =3D 0x20c0a200 r5 =3D 0x000001a4 >>> r6 =3D 0x20cc1198 r7 =3D 0x00000005 >>> r8 =3D 0x20c0a200 r9 =3D 0x00000001 >>> swi_entry() at swi_entry+0x2c >>> pc =3D 0xc0530350 lr =3D 0xc0530350 (swi_entry+0x2c) >>> sp =3D 0xdd6ffe60 fp =3D 0xbfffe960 >>> Unable to unwind further >>> lock order reversal: >>> 1st 0xc2c06814 ufs (ufs) @ >>> /root/crochet-freebsd/src/sys/kern/vfs_subr.c:2099 >>> 2nd 0xcd1299d0 bufwait (bufwait) @ >>> /root/crochet-freebsd/src/sys/ufs/ffs/ffs_vnops.c:262 >>> 3rd 0xc2cb9154 ufs (ufs) @ >>> /root/crochet-freebsd/src/sys/kern/vfs_subr.c:2099 >>> KDB: stack backtrace: >>> db_trace_self() at db_trace_self >>> pc =3D 0xc052ecf4 lr =3D 0xc022dcd0 = (db_trace_self_wrapper+0x30) >>> sp =3D 0xdd6ff578 fp =3D 0xdd6ff690 >>> r10 =3D 0xc05adb30 >>> db_trace_self_wrapper() at db_trace_self_wrapper+0x30 >>> pc =3D 0xc022dcd0 lr =3D 0xc038e9e0 (kdb_backtrace+0x38) >>> sp =3D 0xdd6ff698 fp =3D 0xdd6ff6a0 >>> r4 =3D 0xc066a484 r5 =3D 0xc0592f71 >>> r6 =3D 0xc059b3d0 r7 =3D 0xc05adb33 >>> kdb_backtrace() at kdb_backtrace+0x38 >>> pc =3D 0xc038e9e0 lr =3D 0xc03a8b5c = (witness_checkorder+0xda0) >>> sp =3D 0xdd6ff6a8 fp =3D 0xdd6ff6f8 >>> r4 =3D 0xc0581d1c >>> witness_checkorder() at witness_checkorder+0xda0 >>> pc =3D 0xc03a8b5c lr =3D 0xc033c5fc (__lockmgr_args+0x698) >>> sp =3D 0xdd6ff700 fp =3D 0xdd6ff768 >>> r4 =3D 0x00080100 r5 =3D 0x00000833 >>> r6 =3D 0xc2cb9154 r7 =3D 0x00080000 >>> r8 =3D 0x00000100 r9 =3D 0x00000000 >>> r10 =3D 0xc059b3cd >>> __lockmgr_args() at __lockmgr_args+0x698 >>> pc =3D 0xc033c5fc lr =3D 0xc04e678c (ffs_lock+0x80) >>> sp =3D 0xdd6ff770 fp =3D 0xdd6ff798 >>> r4 =3D 0xdd6ff7b8 r5 =3D 0x00080100 >>> r6 =3D 0xc2cb9120 r7 =3D 0xc2cb9154 >>> r8 =3D 0xc2cb9174 r9 =3D 0x00000000 >>> r10 =3D 0xc059b3cd >>> ffs_lock() at ffs_lock+0x80 >>> pc =3D 0xc04e678c lr =3D 0xc0554118 (VOP_LOCK1_APV+0xd8) >>> sp =3D 0xdd6ff7a0 fp =3D 0xdd6ff7b0 >>> r4 =3D 0xdd6ff7b8 r5 =3D 0xc064e690 >>> r6 =3D 0x00000000 r7 =3D 0x00000000 >>> r8 =3D 0xc2a2d640 r9 =3D 0x00000833 >>> VOP_LOCK1_APV() at VOP_LOCK1_APV+0xd8 >>> pc =3D 0xc0554118 lr =3D 0xc0408cbc (_vn_lock+0x78) >>> sp =3D 0xdd6ff7b8 fp =3D 0xdd6ff7e8 >>> r4 =3D 0xc2cb9120 r5 =3D 0x00080100 >>> r6 =3D 0x00080100 >>> _vn_lock() at _vn_lock+0x78 >>> pc =3D 0xc0408cbc lr =3D 0xc03f97e8 (vget+0x60) >>> sp =3D 0xdd6ff7f0 fp =3D 0xdd6ff810 >>> r4 =3D 0xc2cb9120 r5 =3D 0x00000000 >>> r6 =3D 0x00080100 r7 =3D 0x00000000 >>> r8 =3D 0xc2a2d640 r9 =3D 0xc059a607 >>> r10 =3D 0x00000000 >>> vget() at vget+0x60 >>> pc =3D 0xc03f97e8 lr =3D 0xc03ede5c (vfs_hash_get+0xe4) >>> sp =3D 0xdd6ff818 fp =3D 0xdd6ff848 >>> r4 =3D 0xc2a0b2b0 r5 =3D 0x00000000 >>> r6 =3D 0x0002787d r7 =3D 0x00000000 >>> r8 =3D 0xc2cb9120 >>> vfs_hash_get() at vfs_hash_get+0xe4 >>> pc =3D 0xc03ede5c lr =3D 0xc04e17f4 (ffs_vgetf+0x3c) >>> sp =3D 0xdd6ff850 fp =3D 0xdd6ff8a0 >>> r4 =3D 0x0002787d r5 =3D 0xc05aa74b >>> r6 =3D 0xc2bb13c0 r7 =3D 0xdd6ff908 >>> r8 =3D 0xc2bb13c0 r9 =3D 0x00080000 >>> r10 =3D 0xc2a0b2b0 >>> ffs_vgetf() at ffs_vgetf+0x3c >>> pc =3D 0xc04e17f4 lr =3D 0xc04da468 = (softdep_sync_buf+0x974) >>> sp =3D 0xdd6ff8a8 fp =3D 0xdd6ff928 >>> r4 =3D 0x0002787d r5 =3D 0xc05aa74b >>> r6 =3D 0xc2bb13c0 r7 =3D 0xc05aa74b >>> r8 =3D 0xc2bb13c0 r9 =3D 0x0000088b >>> r10 =3D 0x0002787d >>> softdep_sync_buf() at softdep_sync_buf+0x974 >>> pc =3D 0xc04da468 lr =3D 0xc04e7560 (ffs_syncvnode+0x2bc) >>> sp =3D 0xdd6ff930 fp =3D 0xdd6ff980 >>> r4 =3D 0x00000000 r5 =3D 0xcd188d48 >>> r6 =3D 0x00060200 r7 =3D 0xc2c067e0 >>> r8 =3D 0xc05adb30 r9 =3D 0xcd1299d0 >>> r10 =3D 0xcd129978 >>> ffs_syncvnode() at ffs_syncvnode+0x2bc >>> pc =3D 0xc04e7560 lr =3D 0xc04e6650 (ffs_fsync+0x20) >>> sp =3D 0xdd6ff988 fp =3D 0xdd6ff998 >>> r4 =3D 0xdd6ff9f0 r5 =3D 0xc2c067e0 >>> r6 =3D 0x00000000 r7 =3D 0x00000200 >>> r8 =3D 0xc2a2d640 r9 =3D 0xc2c067e0 >>> r10 =3D 0xc33445a0 >>> ffs_fsync() at ffs_fsync+0x20 >>> pc =3D 0xc04e6650 lr =3D 0xc05534b8 (VOP_FSYNC_APV+0xd0) >>> sp =3D 0xdd6ff9a0 fp =3D 0xdd6ff9b0 >>> r4 =3D 0xdd6ff9f0 r5 =3D 0xc064e690 >>> r6 =3D 0x00000000 r7 =3D 0x00000200 >>> VOP_FSYNC_APV() at VOP_FSYNC_APV+0xd0 >>> pc =3D 0xc05534b8 lr =3D 0xc04eeb54 (ufs_direnter+0x724) >>> sp =3D 0xdd6ff9b8 fp =3D 0xdd6ffa20 >>> r4 =3D 0xc33445a0 r5 =3D 0x00000000 >>> r6 =3D 0xcd356e00 >>> ufs_direnter() at ufs_direnter+0x724 >>> pc =3D 0xc04eeb54 lr =3D 0xc04f7e04 (ufs_makeinode+0x3f4) >>> sp =3D 0xdd6ffa28 fp =3D 0xdd6ffb88 >>> r4 =3D 0xdd6ffa48 r5 =3D 0xc332fa00 >>> r6 =3D 0xdd6ffd48 r7 =3D 0x00000000 >>> r8 =3D 0xc2c067e0 r9 =3D 0xdd6ffd30 >>> r10 =3D 0x000081a4 >>> ufs_makeinode() at ufs_makeinode+0x3f4 >>> pc =3D 0xc04f7e04 lr =3D 0xc04f4268 (ufs_create+0x24) >>> sp =3D 0xdd6ffb90 fp =3D 0xdd6ffb90 >>> r4 =3D 0xdd6ffc60 r5 =3D 0xc064eba0 >>> r6 =3D 0x00000000 r7 =3D 0x00100a02 >>> r8 =3D 0x00000000 r9 =3D 0xdd6ffd30 >>> r10 =3D 0xdd6ffd50 >>> ufs_create() at ufs_create+0x24 >>> pc =3D 0xc04f4268 lr =3D 0xc0552268 (VOP_CREATE_APV+0xd0) >>> sp =3D 0xdd6ffb98 fp =3D 0xdd6ffba8 >>> VOP_CREATE_APV() at VOP_CREATE_APV+0xd0 >>> pc =3D 0xc0552268 lr =3D 0xc0408540 (vn_open_cred+0x278) >>> sp =3D 0xdd6ffbb0 fp =3D 0xdd6ffc90 >>> r4 =3D 0xdd6ffce0 r5 =3D 0xdd6ffd30 >>> r6 =3D 0xc2c067e0 >>> vn_open_cred() at vn_open_cred+0x278 >>> pc =3D 0xc0408540 lr =3D 0xc04082c0 (vn_open+0x24) >>> sp =3D 0xdd6ffc98 fp =3D 0xdd6ffca0 >>> r4 =3D 0xc2a2d640 r5 =3D 0xc2a76000 >>> r6 =3D 0xdd6ffce0 r7 =3D 0x00000012 >>> r8 =3D 0x00000000 r9 =3D 0x000500cf >>> r10 =3D 0xdd6ffcd0 >>> vn_open() at vn_open+0x24 >>> pc =3D 0xc04082c0 lr =3D 0xc040187c (kern_openat+0x24c) >>> sp =3D 0xdd6ffca8 fp =3D 0xdd6ffda8 >>> kern_openat() at kern_openat+0x24c >>> pc =3D 0xc040187c lr =3D 0xc04015c4 (sys_open+0x28) >>> sp =3D 0xdd6ffdb0 fp =3D 0xdd6ffdb8 >>> r4 =3D 0xc2a2d640 r5 =3D 0x00000000 >>> r6 =3D 0x20cc1198 r7 =3D 0x00000000 >>> r8 =3D 0xdd6ffe10 r9 =3D 0xc29f6c80 >>> r10 =3D 0x20c24080 >>> sys_open() at sys_open+0x28 >>> pc =3D 0xc04015c4 lr =3D 0xc0540764 (swi_handler+0x284) >>> sp =3D 0xdd6ffdc0 fp =3D 0xdd6ffe58 >>> swi_handler() at swi_handler+0x284 >>> pc =3D 0xc0540764 lr =3D 0xc0530350 (swi_entry+0x2c) >>> sp =3D 0xdd6ffe60 fp =3D 0xbfffe960 >>> r4 =3D 0x20c0a200 r5 =3D 0x000001a4 >>> r6 =3D 0x20cc1198 r7 =3D 0x00000 >>> _______________________________________________ >>> 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" >>=20 >> _______________________________________________ >> 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" >=20 ------------------------------ Randall Stewart 803-317-4952 (cell) From owner-freebsd-arm@FreeBSD.ORG Sat Sep 21 18:25:25 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 84AAB9BD for ; Sat, 21 Sep 2013 18:25:25 +0000 (UTC) (envelope-from tim@kientzle.com) Received: from monday.kientzle.com (99-115-135-74.uvs.sntcca.sbcglobal.net [99.115.135.74]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 471CA20DE for ; Sat, 21 Sep 2013 18:25:24 +0000 (UTC) Received: (from root@localhost) by monday.kientzle.com (8.14.4/8.14.4) id r8LIPHOq003089; Sat, 21 Sep 2013 18:25:17 GMT (envelope-from tim@kientzle.com) Received: from [192.168.2.123] (CiscoE3000 [192.168.1.65]) by kientzle.com with SMTP id u586pnwv952k9ezsm6dxgkmhdi; Sat, 21 Sep 2013 18:25:16 +0000 (UTC) (envelope-from tim@kientzle.com) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Subject: Re: Progress on Raspberry Pi From: Tim Kientzle In-Reply-To: <523CED09.2010509@m5p.com> Date: Sat, 21 Sep 2013 11:25:15 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <155A28EF-C877-4E21-8DAD-55B48F42A661@kientzle.com> References: <523CED09.2010509@m5p.com> To: George Mitchell X-Mailer: Apple Mail (2.1508) Cc: "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Sep 2013 18:25:25 -0000 On Sep 20, 2013, at 5:49 PM, George Mitchell = wrote: > My AdaFruit serial cable arrived, so now I can gather useful = information > when my RPi crashes=85 Excellent! > I built my image with crochet on an amd64 running r255361, and the = image > itself is based on that version. (However, in sys/arm/arm I updated > pmap-v6.c to 255612 and stdatomic.c to 255613. I see they have been > updated again within the last day; perhaps I should try again.) >=20 > /etc/src.conf: > MALLOC_PRODUCTION=3Dyes >=20 > /etc/make.conf: > WITH_PKGNG=3Dyes > MALLOC_PRODUCTION=3Dyes > # added by use.perl 2013-08-20 10:11:49 > PERL_VERSION=3D5.14.4 By default, Crochet ignores the host /etc/src.conf and /etc/make.conf on the assumption that what is right for the host system is not necessarily correct for the target system. If you specifically want to use them, you can add SRCCONF=3D/etc/src.conf __MAKE_CONF=3D/etc/make.conf to your configuration file. Of course, you can also put src.conf and make.conf files elsewhere for Crochet to use. > I commented out the five syscons-related lines in sys/arm/conf/RPI-B = so > I could use the serial port. My SDHC card is apparently on the hairy > edge of working, so I definitely needed /boot/loader.conf to contain: > hw.bcm2835.sdhci.hs=3D0. Before I added that, I ended up with the = dreaded > error 19 and a manual mountroot prompt, at which point mountroot would > accept a character from the serial input about 1/4 of the time. Other > serial input works without a problem. Keyboard input to mount root seems to be broken on a lot of FreeBSD systems. > Before I remembered to comment out the /dev/ttyvN lines in /etc/tty,=85 Should Crochet's RaspberryPi configuration disable those? > 2. Now that I can do something when I get the prefetch abort or panic, > what should I do at the "db>" prompt to help debug it? It's happening > about five or six times a day. Type "bt" to get a backtrace. That's the single most informative thing. Note: The first few stack frames displayed are from inside the debugger itself and aren't particularly interesting. The important frames are a little later where we see *why* we ended up in the debugger. Tim From owner-freebsd-arm@FreeBSD.ORG Sat Sep 21 18:35:11 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 5D167B15 for ; Sat, 21 Sep 2013 18:35:11 +0000 (UTC) (envelope-from tim@kientzle.com) Received: from monday.kientzle.com (99-115-135-74.uvs.sntcca.sbcglobal.net [99.115.135.74]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 2CFDB21A0 for ; Sat, 21 Sep 2013 18:35:10 +0000 (UTC) Received: (from root@localhost) by monday.kientzle.com (8.14.4/8.14.4) id r8LIZ6GN003137; Sat, 21 Sep 2013 18:35:06 GMT (envelope-from tim@kientzle.com) Received: from [192.168.2.123] (CiscoE3000 [192.168.1.65]) by kientzle.com with SMTP id y2nevyjxmug26nj3q38y9n7kke; Sat, 21 Sep 2013 18:35:06 +0000 (UTC) (envelope-from tim@kientzle.com) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Subject: Re: freebsd on beaglebone black, lock reversal panic shortly after first boot From: Tim Kientzle In-Reply-To: Date: Sat, 21 Sep 2013 11:35:06 -0700 Content-Transfer-Encoding: 7bit Message-Id: <23F2AC2E-E8C2-4C2E-8E0E-4F1A31DDA6FA@kientzle.com> References: To: David Cheney X-Mailer: Apple Mail (2.1508) Cc: freebsd-arm@freebsd.org, Ronald Klop X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Sep 2013 18:35:11 -0000 On Sep 21, 2013, at 2:53 AM, David Cheney wrote: > Ronald, > > Thanks for your reply. I'm sorry, I am inexperienced with this sort of > thing, the machine has not crash, in fact it still building a port > now. From my linux background, if I saw that much output, the host > would be kerput. FreeBSD on BBB is running a development kernel right now. As a result, it has some internal check code that reports "possible errors" very verbosely. Not all of the things reported by these checks are real problems. When FreeBSD-10 is officially released later this year we will have production versions of FreeBSD. If you build your own FreeBSD image, you can also disable these additional checks. In particular, development FreeBSD kernels include a subsystem called "WITNESS" which verifies how the various parts of the kernel use locks. WITNESS is normally not enabled on production kernels because the additional checks do slow the system down significantly. A "Lock-order reversal" (LoR) is a common problem with complex multi-threaded code (such as operating system kernels) which can *sometimes* cause the system to freeze or crash. LoRs are one of several issues that WITNESS was designed to check for. In FreeBSD terminology a "panic" is a kernel crash. On development kernels, this will usually drop you immediately into the kernel debugger. On production kernels, a panic usually leads the system to immediately reboot. The two LoRs you saw here are: 1) bufwait/dirhash reversal. lock order reversal: 1st 0xcd1299d0 bufwait (bufwait) @ /root/crochet-freebsd/src/sys/kern/vfs_bio.c:3059 2nd 0xc2a8f600 dirhash (dirhash) @ /root/crochet-freebsd/src/sys/ufs/ufs/ufs_dirhash.c:284 2) ufs/bufwait reversal. lock order reversal: 1st 0xc2c06814 ufs (ufs) @ /root/crochet-freebsd/src/sys/kern/vfs_subr.c:2099 2nd 0xcd1299d0 bufwait (bufwait) @ /root/crochet-freebsd/src/sys/ufs/ffs/ffs_vnops.c:262 3rd 0xc2cb9154 ufs (ufs) @ /root/crochet-freebsd/src/sys/kern/vfs_subr.c:2099 I believe both of these are "false positives". They are not a real problem but WITNESS doesn't have quite enough context to know that. If I understand correctly, filesystem locks are claimed in a particular order determined by the filesystem structure; WITNESS only knows the names of the locks, not what filesystem objects they refer to, so it can't really tell if the order is correct or not. There are a couple of other pretty common LoR false positives. You'll start to recognize those pretty soon. If you see *new* LoRs, we're very interested. Tim From owner-freebsd-arm@FreeBSD.ORG Sat Sep 21 19:01:39 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id CD4A2E6E for ; Sat, 21 Sep 2013 19:01:39 +0000 (UTC) (envelope-from george+freebsd@m5p.com) Received: from mailhost.m5p.com (ip-2-1-0-2.r03.asbnva02.us.ce.gin.ntt.net [IPv6:2001:418:0:5000::16]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 941972361 for ; Sat, 21 Sep 2013 19:01:39 +0000 (UTC) Received: from wonderland.m5p.com (localhost [IPv6:::1]) by mailhost.m5p.com (8.14.5/8.14.5) with ESMTP id r8LJ1WjO080888; Sat, 21 Sep 2013 15:01:37 -0400 (EDT) (envelope-from george+freebsd@m5p.com) Message-ID: <523DED0C.8010403@m5p.com> Date: Sat, 21 Sep 2013 15:01:32 -0400 From: George Mitchell User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130716 Thunderbird/17.0.7 MIME-Version: 1.0 To: Tim Kientzle Subject: Re: Progress on Raspberry Pi References: <523CED09.2010509@m5p.com> <155A28EF-C877-4E21-8DAD-55B48F42A661@kientzle.com> In-Reply-To: <155A28EF-C877-4E21-8DAD-55B48F42A661@kientzle.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.73 on 10.100.0.3 X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.7 (mailhost.m5p.com [IPv6:::1]); Sat, 21 Sep 2013 15:01:38 -0400 (EDT) Cc: "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Sep 2013 19:01:40 -0000 On 09/21/13 14:25, Tim Kientzle wrote: > > On Sep 20, 2013, at 5:49 PM, George Mitchell wrote: > >> My AdaFruit serial cable arrived, so now I can gather useful information >> when my RPi crashes… > > Excellent! > >> I built my image with crochet on an amd64 running r255361, and the image >> itself is based on that version. (However, in sys/arm/arm I updated >> pmap-v6.c to 255612 and stdatomic.c to 255613. I see they have been >> updated again within the last day; perhaps I should try again.) >> >> /etc/src.conf: >> MALLOC_PRODUCTION=yes >> >> /etc/make.conf: >> WITH_PKGNG=yes >> MALLOC_PRODUCTION=yes >> # added by use.perl 2013-08-20 10:11:49 >> PERL_VERSION=5.14.4 > > By default, Crochet ignores the host /etc/src.conf > and /etc/make.conf on the assumption that what > is right for the host system is not necessarily correct > for the target system. > > If you specifically want to use them, you can add > > SRCCONF=/etc/src.conf > __MAKE_CONF=/etc/make.conf > > to your configuration file. Of course, you can also put > src.conf and make.conf files elsewhere for Crochet to use. Thanks! I put that in my crochet config file just a couple of weeks ago when you first mentioned it. > >> I commented out the five syscons-related lines in sys/arm/conf/RPI-B so >> I could use the serial port. My SDHC card is apparently on the hairy >> edge of working, so I definitely needed /boot/loader.conf to contain: >> hw.bcm2835.sdhci.hs=0. Before I added that, I ended up with the dreaded >> error 19 and a manual mountroot prompt, at which point mountroot would >> accept a character from the serial input about 1/4 of the time. Other >> serial input works without a problem. > > Keyboard input to mount root seems to > be broken on a lot of FreeBSD systems. > >> Before I remembered to comment out the /dev/ttyvN lines in /etc/tty,… > > Should Crochet's RaspberryPi configuration disable those? Not sure. Before I got the serial cable hooked up, it was nice to be able to use the USB keyboard to log into the system. > >> 2. Now that I can do something when I get the prefetch abort or panic, >> what should I do at the "db>" prompt to help debug it? It's happening >> about five or six times a day. > > Type "bt" to get a backtrace. That's the single most informative > thing. Note: The first few stack frames displayed are from inside > the debugger itself and aren't particularly interesting. The important > frames are a little later where we see *why* we ended up in the > debugger. > > Tim > Okay, will do. I'll try to collect a few and maybe post them in the few days. Any predictions of what will happen if I try to compile and install x11/xorg on the RPi? -- George From owner-freebsd-arm@FreeBSD.ORG Sat Sep 21 21:07:48 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 0D3D61A7 for ; Sat, 21 Sep 2013 21:07:48 +0000 (UTC) (envelope-from george+freebsd@m5p.com) Received: from mailhost.m5p.com (ip-2-1-0-2.r03.asbnva02.us.ce.gin.ntt.net [IPv6:2001:418:0:5000::16]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 9D36428B8 for ; Sat, 21 Sep 2013 21:07:47 +0000 (UTC) Received: from wonderland.m5p.com (localhost [IPv6:::1]) by mailhost.m5p.com (8.14.5/8.14.5) with ESMTP id r8LL7eDg081771; Sat, 21 Sep 2013 17:07:45 -0400 (EDT) (envelope-from george+freebsd@m5p.com) Message-ID: <523E0A9C.6000505@m5p.com> Date: Sat, 21 Sep 2013 17:07:40 -0400 From: George Mitchell User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130716 Thunderbird/17.0.7 MIME-Version: 1.0 To: Tim Kientzle , "freebsd-arm@freebsd.org" Subject: Re: Progress on Raspberry Pi References: <523CED09.2010509@m5p.com> <155A28EF-C877-4E21-8DAD-55B48F42A661@kientzle.com> <523DED0C.8010403@m5p.com> In-Reply-To: <523DED0C.8010403@m5p.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.73 on 10.100.0.3 X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.7 (mailhost.m5p.com [IPv6:::1]); Sat, 21 Sep 2013 17:07:46 -0400 (EDT) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Sep 2013 21:07:48 -0000 On 09/21/13 15:01, George Mitchell wrote: > On 09/21/13 14:25, Tim Kientzle wrote: >>[...] >>> 2. Now that I can do something when I get the prefetch abort or panic, >>> what should I do at the "db>" prompt to help debug it? It's happening >>> about five or six times a day. >> >> Type "bt" to get a backtrace. That's the single most informative >> thing. Note: The first few stack frames displayed are from inside >> the debugger itself and aren't particularly interesting. The important >> frames are a little later where we see *why* we ended up in the >> debugger. >> >> Tim >> > > Okay, will do. I'll try to collect a few and maybe post them in the > few days. > > Any predictions of what will happen if I try to compile and install > x11/xorg on the RPi? -- George It appears that "t" is the command to use here. The first one is in: http://www.m5p.com/~george/pi/trace1.txt along with kernel.tbz, which includes my /boot/kernel/kernel.symbols, /boot/kernel/kernel, and kernel/kernel.gz.tramp (don't know what that is, but my tar command picked it up). Perhaps that will help decipher the addresses in the backtrace. This one occurred while I was re-running "portmaster -BDg devel/glib20" under the script command to see why the whole "gio" include directory isn't getting installed. Using MALLOC_PRODUCTION=yes doesn't seem to have cured this problem -- George