From owner-freebsd-arm@FreeBSD.ORG Sun Aug 25 05:51:45 2013 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 2623734C; Sun, 25 Aug 2013 05:51:45 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id E54BF2997; Sun, 25 Aug 2013 05:51:44 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r7P5phx4078704; Sun, 25 Aug 2013 01:51:43 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r7P5phtY078694; Sun, 25 Aug 2013 05:51:43 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 25 Aug 2013 05:51:43 GMT Message-Id: <201308250551.r7P5phtY078694@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on arm/arm Precedence: bulk X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Aug 2013 05:51:45 -0000 TB --- 2013-08-25 02:30:25 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-08-25 02:30:25 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-08-25 02:30:25 - starting HEAD tinderbox run for arm/arm TB --- 2013-08-25 02:30:25 - cleaning the object tree TB --- 2013-08-25 02:36:57 - /usr/local/bin/svn stat /src TB --- 2013-08-25 02:37:00 - At svn revision 254824 TB --- 2013-08-25 02:37:01 - building world TB --- 2013-08-25 02:37:01 - CROSS_BUILD_TESTING=YES TB --- 2013-08-25 02:37:01 - MAKEOBJDIRPREFIX=/obj TB --- 2013-08-25 02:37:01 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-08-25 02:37:01 - SRCCONF=/dev/null TB --- 2013-08-25 02:37:01 - TARGET=arm TB --- 2013-08-25 02:37:01 - TARGET_ARCH=arm TB --- 2013-08-25 02:37:01 - TZ=UTC TB --- 2013-08-25 02:37:01 - __MAKE_CONF=/dev/null TB --- 2013-08-25 02:37:01 - cd /src TB --- 2013-08-25 02:37:01 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Sun Aug 25 02:37:09 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Sun Aug 25 05:39:54 UTC 2013 TB --- 2013-08-25 05:39:54 - generating LINT kernel config TB --- 2013-08-25 05:39:54 - cd /src/sys/arm/conf TB --- 2013-08-25 05:39:54 - /usr/bin/make -B LINT TB --- 2013-08-25 05:39:54 - cd /src/sys/arm/conf TB --- 2013-08-25 05:39:54 - /usr/sbin/config -m LINT TB --- 2013-08-25 05:39:54 - building LINT kernel TB --- 2013-08-25 05:39:54 - CROSS_BUILD_TESTING=YES TB --- 2013-08-25 05:39:54 - MAKEOBJDIRPREFIX=/obj TB --- 2013-08-25 05:39:54 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-08-25 05:39:54 - SRCCONF=/dev/null TB --- 2013-08-25 05:39:54 - TARGET=arm TB --- 2013-08-25 05:39:54 - TARGET_ARCH=arm TB --- 2013-08-25 05:39:54 - TZ=UTC TB --- 2013-08-25 05:39:54 - __MAKE_CONF=/dev/null TB --- 2013-08-25 05:39:54 - cd /src TB --- 2013-08-25 05:39:54 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sun Aug 25 05:39:55 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ /src/sys/sys/mbuf.h:760:50: note: expanded from macro 'MEXTADD' (void )m_extadd((m), (caddr_t)(buf), (size), (free), (arg1), (arg2),\ ^~~~~~ /src/sys/sys/mbuf.h:898:14: note: passing argument to parameter here void (*)(struct mbuf *, void *, void *), void *, void *, ^ 1 error generated. *** Error code 1 Stop. bmake[1]: stopped in /obj/arm.arm/src/sys/LINT *** Error code 1 Stop. bmake: stopped in /src *** Error code 1 Stop in /src. TB --- 2013-08-25 05:51:43 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-08-25 05:51:43 - ERROR: failed to build LINT kernel TB --- 2013-08-25 05:51:43 - 9180.37 user 1670.27 system 12077.28 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-arm-arm.full From owner-freebsd-arm@FreeBSD.ORG Sun Aug 25 07:56: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 4AB15E7 for ; Sun, 25 Aug 2013 07:56:16 +0000 (UTC) (envelope-from jiashiun@gmail.com) Received: from mail-oa0-x22b.google.com (mail-oa0-x22b.google.com [IPv6:2607:f8b0:4003:c02::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 15E0A2EE2 for ; Sun, 25 Aug 2013 07:56:16 +0000 (UTC) Received: by mail-oa0-f43.google.com with SMTP id i10so2438526oag.2 for ; Sun, 25 Aug 2013 00:56:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=ByKRYVoxyblnKAyvYKaSGFabclQOthT837o2hGtMngM=; b=MSR7qeZ0X9LfVlaj9LLVyTNSVJg5hHa/xyTBpOdfuA9zVCWzxSYl+93tjv0y2mVAOj GQ1Y/CVMGCaTy7pgHTfPN9FCa77dTrtUapCx6u7RMMQNzDtIePk9nb6jy7HWFP6F4Y9d ljJoqgIIF/na2WkpI2/RUd0GXIxco5WC/s+Fw0hcoW/DLe8plp7gEnkfvNgFhTNAI4W1 AYa7X0GhSnDOpCZLJKdYH7oGsPzfe2Li5CNzFoh0qXwH5Q1ryf1ZZRxxeGHum67Yy9No MGKoUx4uxDBKkmAUMB5/0DUocZfkZgHay5O9KTuQLCbOKaIMbI7s713Vfz69P7az/rIJ qYKQ== X-Received: by 10.182.43.132 with SMTP id w4mr8201246obl.25.1377417375135; Sun, 25 Aug 2013 00:56:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.76.131.111 with HTTP; Sun, 25 Aug 2013 00:55:44 -0700 (PDT) In-Reply-To: <5218FBE2.2000907@m5p.com> References: <5218FBE2.2000907@m5p.com> From: Jia-Shiun Li Date: Sun, 25 Aug 2013 15:55:44 +0800 Message-ID: Subject: Re: Pretty good RPi version? To: George Mitchell Content-Type: text/plain; charset=UTF-8 Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Aug 2013 07:56:16 -0000 On Sun, Aug 25, 2013 at 2:30 AM, George Mitchell wrote: > What's a pretty good recent Raspberry Pi svn checkout version? 254544 > doesn't seem to be it -- it crashes as soon as I try to make install in > /usr/ports/ports-mgmt/pkg. Although I'm tempted to grab one of the > prebuilt images at http://www.db.net/downloads/, I'll have to be doing > some recompiling for debug purposes. I see that latest couple of > versions there are 252209 and 250580. Are those pretty good? (By > "pretty good", I mean capable of running a light load in a fairly > stable way over a period of days.) Thanks for your help! -- George I got the same question. I was trying to update RPi this week, but several attempts has failed. RPi would hang at high load like "portsnap fetch extract" or "cd /usr/ports/graphics/graphviz && make install clean". By "hang" I mean ssh session and console had no response. But it still replies to ICMP and TCP connection handshake requests. Looks like something got stuck in the kernel. I am falling back to image built as of 19 July. So far it looks stable enough. That's is before switching to AEABI, recent VM changes, and llvm still having problem building some ports. Regards, Jia-Shiun. From owner-freebsd-arm@FreeBSD.ORG Sun Aug 25 08:43: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 20DDEAA2; Sun, 25 Aug 2013 08:43:42 +0000 (UTC) (envelope-from hps@bitfrost.no) Received: from mta.bitpro.no (mta.bitpro.no [92.42.64.202]) by mx1.freebsd.org (Postfix) with ESMTP id CE122214C; Sun, 25 Aug 2013 08:43:41 +0000 (UTC) Received: from mail.lockless.no (mail.lockless.no [46.29.221.38]) by mta.bitpro.no (Postfix) with ESMTP id ED1E97A352; Sun, 25 Aug 2013 10:43:33 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mail.lockless.no (Postfix) with ESMTP id B53448EFECD; Sun, 25 Aug 2013 10:43:45 +0200 (CEST) X-Virus-Scanned: by amavisd-new-2.6.4 (20090625) (Debian) at lockless.no Received: from mail.lockless.no ([127.0.0.1]) by localhost (mail.lockless.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RGh1tbsCFEfw; Sun, 25 Aug 2013 10:43:45 +0200 (CEST) Received: from laptop015.home.selasky.org (cm-176.74.213.204.customer.telag.net [176.74.213.204]) by mail.lockless.no (Postfix) with ESMTPSA id 212968EFECC; Sun, 25 Aug 2013 10:43:45 +0200 (CEST) Message-ID: <5219C3FF.1070509@bitfrost.no> Date: Sun, 25 Aug 2013 10:44:47 +0200 From: Hans Petter Selasky Organization: Bitfrost A/S User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130522 Thunderbird/17.0.6 MIME-Version: 1.0 To: George Mitchell Subject: Re: ulpt can't attach Lexmark E120 References: <5105527F.3010708@m5p.com> <201301271915.47712.hselasky@c2i.net> <510570C1.1060607@m5p.com> <201301272007.30682.hselasky@c2i.net> <5105AB16.2000607@m5p.com> <5215F4DF.6000305@m5p.com> <5215F743.8060403@bitfrost.no> <5216ACE5.7000500@m5p.com> <5216FE9F.2030608@bitfrost.no> <52174378.2020101@m5p.com> <521801E5.9000309@m5p.com> <52184F59.5080100@bitfrost.no> <5218F993.9050504@m5p.com> In-Reply-To: <5218F993.9050504@m5p.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-arm@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: Sun, 25 Aug 2013 08:43:42 -0000 On 08/24/13 20:21, George Mitchell wrote: > > Setting hw.usb.dwc_otg.debug to any value greater than 0 generates an > unending stream of debug output and effectively locks up the chip > scrolling the output on the display. Perhaps there are some specific > debug messages I could put in ... -- George Hi, Can you try this patch: http://svnweb.freebsd.org/changeset/base/254828 --HPS From owner-freebsd-arm@FreeBSD.ORG Sun Aug 25 11:16:05 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 4CCA27FA for ; Sun, 25 Aug 2013 11:16:05 +0000 (UTC) (envelope-from shigeru@os-hackers.jp) Received: from mail2.asahi-net.or.jp (mail2.asahi-net.or.jp [202.224.39.198]) by mx1.freebsd.org (Postfix) with ESMTP id 21E3A2807 for ; Sun, 25 Aug 2013 11:16:04 +0000 (UTC) Received: from localhost (w142149.ppp.asahi-net.or.jp [121.1.142.149]) by mail2.asahi-net.or.jp (Postfix) with ESMTP id EAE2B40558; Sun, 25 Aug 2013 19:56:44 +0900 (JST) Date: Sun, 25 Aug 2013 19:55:32 +0900 (JST) Message-Id: <20130825.195532.59669686.shigeru@os-hackers.jp> To: george+freebsd@m5p.com Subject: Re: Pretty good RPi version? From: shigeru@os-hackers.jp In-Reply-To: <5218FBE2.2000907@m5p.com> References: <5218FBE2.2000907@m5p.com> X-Mailer: Mew version 3.3 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Aug 2013 11:16:05 -0000 Hi all, >>>>> "George" == George Mitchell writes: George> What's a pretty good recent Raspberry Pi svn checkout version? George> 254544 doesn't seem to be it -- it crashes as soon as I try to make George> install in /usr/ports/ports-mgmt/pkg. Although I'm tempted to grab George> one of the prebuilt images at http://www.db.net/downloads/, I'll George> have to be doing some recompiling for debug purposes. I see that George> latest couple of versions there are 252209 and 250580. Are those George> pretty good? (By "pretty good", I mean capable of running a light George> load in a fairly stable way over a period of days.) Thanks for your George> help! Now I'm using r253877 kernel. It is my private build image. It seems me stable. I make 200 over ports on that kernel. Please use my private build image, if you are interrested in. http://freebsd-current.os-hackers.jp/pub/FreeBSD/snapshots/20130802/raspberry-pi/freebsd-pi-20130802.img Thanks, --- YAMAMOTO Shigeru From owner-freebsd-arm@FreeBSD.ORG Sun Aug 25 12:07: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 9C80F176 for ; Sun, 25 Aug 2013 12:07:38 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-qa0-x22a.google.com (mail-qa0-x22a.google.com [IPv6:2607:f8b0:400d:c00::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 5D6B52A5F for ; Sun, 25 Aug 2013 12:07:38 +0000 (UTC) Received: by mail-qa0-f42.google.com with SMTP id bv4so1913607qab.1 for ; Sun, 25 Aug 2013 05:07:37 -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=/ftzjokS0Dc5dQ9kHuVvSQZKaaK6oc1BuKvKNHsVILw=; b=dAN8sGTe52rPioz6TyVwoF0PdtFfRTfzQQgAoZiS1kyGRlP6bGdlbfimm29AgWeqeG w6r3qp9lJqL92VeNlQjg7qAvPYv6WZg0fc8iRtsx1Hfq1xmgd9K1bW17QQi7G8qua1e1 akYHwEW3mr4nhmF7OErlaquXI7PaOMa+sYdJc4rnoOx/aBcc4EJdE44bC+rtC4lf8gNf xAH3ylr+VEvtE3oiOD7ddVNva70lGz8gSPyjV3ROAEWrt6WvwL/+DDu+uAYP9GIA5w+U AWc/raheuCyIcZ3DdEjgNQm26meO+kxR2CPu+lkIOBqNymQzDa/25WN5BSsSaW7UYC5P X12Q== MIME-Version: 1.0 X-Received: by 10.229.149.147 with SMTP id t19mr112531qcv.95.1377432457612; Sun, 25 Aug 2013 05:07:37 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.224.128.70 with HTTP; Sun, 25 Aug 2013 05:07:37 -0700 (PDT) In-Reply-To: <20130825.195532.59669686.shigeru@os-hackers.jp> References: <5218FBE2.2000907@m5p.com> <20130825.195532.59669686.shigeru@os-hackers.jp> Date: Sun, 25 Aug 2013 05:07:37 -0700 X-Google-Sender-Auth: tblTo-I-BAN-_QM4_95Y8FmVHHo Message-ID: Subject: Re: Pretty good RPi version? From: Adrian Chadd To: "shigeru@os-hackers.jp" 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: Sun, 25 Aug 2013 12:07:38 -0000 Hi! All - if it's unstable, please complain loudly on -arm and -current and file PRs. If you have the time, please help figure out which commit(s) broke things. There's been plenty of "stuff is unstable" talk, but I'm not sure it's percolated its way up to the people doing VM hacking on other platforms (notably amd64) so they are likely unaware they've broken things. It's possible they've also broken things for MIPS, which has me worried. :( Thanks, -adrian From owner-freebsd-arm@FreeBSD.ORG Sun Aug 25 12:11:49 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 29D47301; Sun, 25 Aug 2013 12:11:49 +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 EABA32A98; Sun, 25 Aug 2013 12:11:48 +0000 (UTC) Received: from bender.Home (97e5e46b.skybroadband.com [151.229.228.107]) by nibbler.fubar.geek.nz (Postfix) with ESMTPSA id A4EF95DFF7; Sun, 25 Aug 2013 12:11:40 +0000 (UTC) Date: Sun, 25 Aug 2013 13:11:34 +0100 From: Andrew Turner To: Grzegorz Bernacki Subject: Re: svn commit: r251370 - head/sys/arm/arm Message-ID: <20130825131134.11815f5d@bender.Home> In-Reply-To: <201306040921.r549LI8t021617@svn.freebsd.org> References: <201306040921.r549LI8t021617@svn.freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org, 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, 25 Aug 2013 12:11:49 -0000 On Tue, 4 Jun 2013 09:21:18 +0000 (UTC) Grzegorz Bernacki wrote: > Author: gber > Date: Tue Jun 4 09:21:18 2013 > New Revision: 251370 > URL: http://svnweb.freebsd.org/changeset/base/251370 > > Log: > Implement pmap_copy() for ARMv6/v7. > > Copy the given range of mappings from the source map to the > destination map, thereby reducing the number of VM faults on fork. > > Submitted by: Zbigniew Bodek > Sponsored by: The FreeBSD Foundation, Semihalf > > Modified: > head/sys/arm/arm/pmap-v6.c This change leads to a deadlock when I attempt to run make buildworld on my PandaBoard. The problem is you are locking pvh_global_lock, src_pmap, and dst_pmap then calling pmap_alloc_l2_bucket. This may unlock pvh_global_lock and dst_pmap, but it has no knowledge of src_pmap so it will keep it locked. If another thread needs to lock src_pmap, for example the pagedaemon may in pmap_clearbit, it will lock pvh_global_lock. This will succeed when pmap_alloc_l2_bucket unlocks it. It will then attempt to lock src_pmap but, as it is already locked, it will wait for pmap_copy to unlock it. At this point pmap_alloc_l2_bucket will attempt to lock pvh_global_lock again, however this lock is already held so it waits for the other thread to unlock it. At this point both threads are waiting on each other causing a deadlock. I don't know enough about the pmap or vm code to be able to fix this, other than reverting this commit. Andrew > > Modified: head/sys/arm/arm/pmap-v6.c > ============================================================================== > --- head/sys/arm/arm/pmap-v6.c Tue Jun 4 07:37:06 2013 > (r251369) +++ head/sys/arm/arm/pmap-v6.c Tue Jun 4 09:21:18 > 2013 (r251370) @@ -2966,6 +2966,126 @@ void > pmap_copy(pmap_t dst_pmap, pmap_t src_pmap, vm_offset_t dst_addr, > vm_size_t len, vm_offset_t src_addr) > { > + struct l2_bucket *l2b_src, *l2b_dst; > + struct pv_entry *pve; > + vm_offset_t addr; > + vm_offset_t end_addr; > + vm_offset_t next_bucket; > + u_int flags; > + boolean_t l2b_alloc; > + > + CTR4(KTR_PMAP, "%s: VA = 0x%08x, len = 0x%08x. Will %s\n", > __func__, > + src_addr, len, (dst_addr != src_addr) ? "exit" : "copy"); > + > + if (dst_addr != src_addr) > + return; > + > + rw_wlock(&pvh_global_lock); > + if (dst_pmap < src_pmap) { > + PMAP_LOCK(dst_pmap); > + PMAP_LOCK(src_pmap); > + } else { > + PMAP_LOCK(src_pmap); > + PMAP_LOCK(dst_pmap); > + } > + > + end_addr = src_addr + len; > + addr = src_addr; > + /* > + * Iterate through all used l2_buckets in a given range. > + */ > + while (addr < end_addr) { > + pt_entry_t *src_ptep, *dst_ptep; > + pt_entry_t src_pte; > + > + next_bucket = L2_NEXT_BUCKET(addr); > + /* > + * If the next bucket VA is out of the > + * copy range then set it to end_addr in order > + * to copy all mappings until the given limit. > + */ > + if (next_bucket > end_addr) > + next_bucket = end_addr; > + > + l2b_src = pmap_get_l2_bucket(src_pmap, addr); > + if (l2b_src == NULL) { > + addr = next_bucket; > + continue; > + } > + src_ptep = &l2b_src->l2b_kva[l2pte_index(addr)]; > + > + while (addr < next_bucket) { > + vm_page_t srcmpte; > + > + src_pte = *src_ptep; > + srcmpte = PHYS_TO_VM_PAGE(l2pte_pa(src_pte)); > + /* > + * We only virtual copy managed pages > + */ > + if (srcmpte && (srcmpte->oflags & > VPO_UNMANAGED) == 0) { > + l2b_alloc = FALSE; > + l2b_dst = > pmap_get_l2_bucket(dst_pmap, addr); > + /* > + * Check if the allocation of another > + * l2_bucket is necessary. > + */ > + if (l2b_dst == NULL) { > + l2b_dst = > pmap_alloc_l2_bucket(dst_pmap, > + addr); > + l2b_alloc = TRUE; > + } > + if (l2b_dst == NULL) > + goto out; > + > + dst_ptep = > &l2b_dst->l2b_kva[l2pte_index(addr)]; + > + if (*dst_ptep == 0 && > + (pve = > pmap_get_pv_entry(dst_pmap, TRUE))) { > + /* > + * Check whether the source > mapping is > + * writable and set the > proper flag > + * for a copied mapping so > that right > + * permissions could be set > on the > + * access fault. > + */ > + flags = 0; > + if ((src_pte & L2_APX) == 0) > + flags = PVF_WRITE; > + pmap_enter_pv(srcmpte, pve, > dst_pmap, > + addr, flags); > + /* > + * Clear the modified and > + * accessed (referenced) > flags > + * and don't set the wired > flag > + * during the copy. > + */ > + *dst_ptep = src_pte; > + *dst_ptep &= ~L2_S_REF; > + *dst_ptep |= L2_APX; > + /* > + * Update stats > + */ > + l2b_dst->l2b_occupancy++; > + > dst_pmap->pm_stats.resident_count++; > + } else { > + /* > + * If the l2_bucket was > acquired as > + * a result of allocation > then free it. > + */ > + if (l2b_alloc) > + > pmap_free_l2_bucket(dst_pmap, > + l2b_dst, 1); > + goto out; > + } > + } > + addr += PAGE_SIZE; > + src_ptep++; > + } > + } > +out: > + rw_wunlock(&pvh_global_lock); > + PMAP_UNLOCK(src_pmap); > + PMAP_UNLOCK(dst_pmap); > } > > > > From owner-freebsd-arm@FreeBSD.ORG Sun Aug 25 12:38:51 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 52CA1E29 for ; Sun, 25 Aug 2013 12:38:51 +0000 (UTC) (envelope-from zbb@semihalf.com) Received: from mail-qc0-f179.google.com (mail-qc0-f179.google.com [209.85.216.179]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 12AE42BA1 for ; Sun, 25 Aug 2013 12:38:50 +0000 (UTC) Received: by mail-qc0-f179.google.com with SMTP id n7so145103qcx.24 for ; Sun, 25 Aug 2013 05:38:44 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=X5zAqWbInfB2AQu8UDIvgvsToVtR20DBJ3IZkx6c2X0=; b=YvwfrVjn+VpOEHORMo7NsOH7f6XncC88DGTTT5IYcyqggPRbM6Gacd2OeWAtX1qGOF mGX7eDkVkgkSMWnQpjP1/ICH/zeBLjt4z76GDCtL0ZDu31bJxs+rbhIPB7CLpDa7Xt+P mfyEze0XvN5/uobOjPHXNaDj4wizGoIm+X1ZCO3CkodCmU41oUPizfh1/NnFpU6nsWDT t/z2azbjLk8qhKjby/9VJxpdti6Nn86oKvxKcyf4jKX0UqUOlxxqXZbFw/066OA9rrIz B2V3s6vgh6Y6JXT7jO8sHtWgC7t1JHe7RQO3HT0kgKRQl4+i72GFbv0u4+2O3iQwtBOv +i2A== X-Gm-Message-State: ALoCoQlR8sRfSFOCygs93QU6aY/7B4pFNnV8smGA61m9ku1iHruW9G83Hqw2lMFMKGZSROwa79GC MIME-Version: 1.0 X-Received: by 10.49.0.198 with SMTP id 6mr11198379qeg.48.1377434324485; Sun, 25 Aug 2013 05:38:44 -0700 (PDT) Received: by 10.49.8.20 with HTTP; Sun, 25 Aug 2013 05:38:44 -0700 (PDT) In-Reply-To: <20130825131134.11815f5d@bender.Home> References: <201306040921.r549LI8t021617@svn.freebsd.org> <20130825131134.11815f5d@bender.Home> Date: Sun, 25 Aug 2013 14:38:44 +0200 Message-ID: Subject: Re: svn commit: r251370 - head/sys/arm/arm From: Zbigniew Bodek To: Andrew Turner Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, Grzegorz Bernacki , src-committers@freebsd.org, "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, 25 Aug 2013 12:38:51 -0000 2013/8/25 Andrew Turner > On Tue, 4 Jun 2013 09:21:18 +0000 (UTC) > Grzegorz Bernacki wrote: > > > Author: gber > > Date: Tue Jun 4 09:21:18 2013 > > New Revision: 251370 > > URL: http://svnweb.freebsd.org/changeset/base/251370 > > > > Log: > > Implement pmap_copy() for ARMv6/v7. > > > > Copy the given range of mappings from the source map to the > > destination map, thereby reducing the number of VM faults on fork. > > > > Submitted by: Zbigniew Bodek > > Sponsored by: The FreeBSD Foundation, Semihalf > > > > Modified: > > head/sys/arm/arm/pmap-v6.c > > This change leads to a deadlock when I attempt to run make buildworld > on my PandaBoard. The problem is you are locking > pvh_global_lock, src_pmap, and dst_pmap then calling > pmap_alloc_l2_bucket. > > This may unlock pvh_global_lock and dst_pmap, but it has no knowledge > of src_pmap so it will keep it locked. > > If another thread needs to lock src_pmap, for example the pagedaemon > may in pmap_clearbit, it will lock pvh_global_lock. This will succeed > when pmap_alloc_l2_bucket unlocks it. It will then attempt to lock > src_pmap but, as it is already locked, it will wait for pmap_copy to > unlock it. > > At this point pmap_alloc_l2_bucket will attempt to lock pvh_global_lock > again, however this lock is already held so it waits for the other > thread to unlock it. > > At this point both threads are waiting on each other causing a deadlock. > > I don't know enough about the pmap or vm code to be able to fix this, > other than reverting this commit. > > Andrew > Hello Andrew, Yes, you are right. We've already discussed this with Olivier (who found this and informed me) and decided to comment this out after committing superpages support. Currently there is no other way to fix this due to pmap_alloc_l2_bucket() implementation. If you are in a great hurry with the commit reversal/commenting out pmap_copy() then I see no problem to do so. Best regards Zbyszek Bodek From owner-freebsd-arm@FreeBSD.ORG Sun Aug 25 12:39:55 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 D55A9FA0 for ; Sun, 25 Aug 2013 12:39:55 +0000 (UTC) (envelope-from mailinglists@martinlaabs.de) Received: from relay04.alfahosting-server.de (relay04.alfahosting-server.de [109.237.142.240]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 90B602BB0 for ; Sun, 25 Aug 2013 12:39:55 +0000 (UTC) Received: by relay04.alfahosting-server.de (Postfix, from userid 1001) id D7E5832C1F43; Sun, 25 Aug 2013 14:39:52 +0200 (CEST) X-Spam-DCC: : X-Spam-Level: X-Spam-Status: No, score=0.0 required=7.0 tests=BAYES_50 autolearn=disabled version=3.2.5 Received: from alfa3018.alfahosting-server.de (alfa3018.alfahosting-server.de [109.237.140.30]) by relay04.alfahosting-server.de (Postfix) with ESMTPS id 6511F32C1F46 for ; Sun, 25 Aug 2013 14:39:51 +0200 (CEST) Received: from [192.168.1.55] (p54B33FFE.dip0.t-ipconnect.de [84.179.63.254]) by alfa3018.alfahosting-server.de (Postfix) with ESMTPSA id 2FEAD515CC92 for ; Sun, 25 Aug 2013 14:39:51 +0200 (CEST) Message-ID: <5219FB16.3060905@martinlaabs.de> Date: Sun, 25 Aug 2013 14:39:50 +0200 From: Martin Laabs User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130809 Thunderbird/17.0.8 MIME-Version: 1.0 To: freebsd-arm@freebsd.org Subject: Re: Pretty good RPi version? References: <5218FBE2.2000907@m5p.com> <20130825.195532.59669686.shigeru@os-hackers.jp> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Status: No X-Virus-Checker-Version: clamassassin 1.2.4 with ClamAV 0.97.3/17739/Sun Aug 25 12:48:30 2013 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Aug 2013 12:39:55 -0000 Hi, > All - if it's unstable, please complain loudly on -arm and -current and > file PRs. If you have the time, please help figure out which commit(s) > broke things. All three things? Post on arm-, current- and fill in PRs or is filling a PR sufficient? Best regards, Martin From owner-freebsd-arm@FreeBSD.ORG Sun Aug 25 12:43:36 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 3CBD515C for ; Sun, 25 Aug 2013 12:43:36 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-qc0-x22e.google.com (mail-qc0-x22e.google.com [IPv6:2607:f8b0:400d:c01::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id F1B462BE8 for ; Sun, 25 Aug 2013 12:43:35 +0000 (UTC) Received: by mail-qc0-f174.google.com with SMTP id e10so540698qcy.5 for ; Sun, 25 Aug 2013 05:43:35 -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=Dlf+zmyRHk8CbHYdAXiBOivRLD7osmWuED+Kt7u9ywQ=; b=JpV7z9bX++zlGXE06RiIYykdRaOy5u4fABkDdcbk/HVQN/yvei7Ul7O6eJtY1uCTyu LN6ce1YUyHCEL4GgDaEXKHZp78zZ3H/JpUhZc1uk3wUAUZg4gspHG/L/pR/alCBBXQtR 72YTiSRZfiGvftxFIPbo/3ydiieHfAFJUPvl2VqTfIwAbCCCVa6xn51hBRUbRIJXl/bl GETcj/Z5lsSwjCZRdt+82/DFOjfXis2pDDHKj6KNgAbgyAaiXkEBMkQeve6CXPdswb0h cjwhp1lANNn8Rz9iEHVtT7fzPJJlWFu7NrA9R17hBALReBeLj3HJZkEWcmMi9ZwcvRAl 2vuA== MIME-Version: 1.0 X-Received: by 10.224.20.136 with SMTP id f8mr2587915qab.73.1377434615059; Sun, 25 Aug 2013 05:43:35 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.224.128.70 with HTTP; Sun, 25 Aug 2013 05:43:34 -0700 (PDT) In-Reply-To: <5219FB16.3060905@martinlaabs.de> References: <5218FBE2.2000907@m5p.com> <20130825.195532.59669686.shigeru@os-hackers.jp> <5219FB16.3060905@martinlaabs.de> Date: Sun, 25 Aug 2013 05:43:34 -0700 X-Google-Sender-Auth: X19sKo7LvaUok07XPdTA-wk2OIg Message-ID: Subject: Re: Pretty good RPi version? From: Adrian Chadd To: Martin Laabs 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: Sun, 25 Aug 2013 12:43:36 -0000 I'd file a PR, then post the bug details on -arm and -current (with the PR number) to see if any discussion occurs. -adrian On 25 August 2013 05:39, Martin Laabs wrote: > Hi, > > > All - if it's unstable, please complain loudly on -arm and -current and > > file PRs. If you have the time, please help figure out which commit(s) > > broke things. > > All three things? Post on arm-, current- and fill in PRs or is filling a PR > sufficient? > > > Best regards, > Martin > > _______________________________________________ > 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 Aug 25 14:12:46 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 3256360E for ; Sun, 25 Aug 2013 14:12:46 +0000 (UTC) (envelope-from fabiodive@gmail.com) Received: from mail-ee0-x230.google.com (mail-ee0-x230.google.com [IPv6:2a00:1450:4013: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 BA8FF2F6B for ; Sun, 25 Aug 2013 14:12:45 +0000 (UTC) Received: by mail-ee0-f48.google.com with SMTP id l10so1131647eei.35 for ; Sun, 25 Aug 2013 07:12:44 -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=zMHOLYOVL1tN99u9M8BLJlHIjLye3rj8w6uQ63EW0m0=; b=o69yzWYdpzVhN6R8/znTcImxsEE+xoQlLYXTsNk4ODa2z6gSTT2HEs1lb2PUVXS80t XFPEipgBamrsBNhxNbpFcBsAtaPITMiesfa2pmkMqgQv0nDOo0dMncURAEjWCncYqW3b 3ynasQDJ3WGbKICnB/nBw5sDUbvnTLD3uje++bWOf9Qjryg7YyRdi5viEBjFGTW3JpJK YLT2N+SMtbu7+m9x9sjT00ovJd+xu5Cufz5H7hwXV7REWDVxYMBL1L1IrgMrmL82eatc PrPl6aaHDF0zTMxVKLunfxd4MQHz8EnDrAZ2vVyIdmUxS8A0uJu/cJ7DlcIGJSYyopA+ PujA== X-Received: by 10.14.89.72 with SMTP id b48mr5598252eef.43.1377439964137; Sun, 25 Aug 2013 07:12:44 -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 a1sm14289808eem.1.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 25 Aug 2013 07:12:43 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Subject: Re: SPI driver for RPi From: fabiodive In-Reply-To: <126AAEEA-1F99-42E4-9620-9CB4F3610671@gmail.com> Date: Sun, 25 Aug 2013 15:12:41 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <126AAEEA-1F99-42E4-9620-9CB4F3610671@gmail.com> To: Luiz Otavio O Souza X-Mailer: Apple Mail (2.1508) Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Aug 2013 14:12:46 -0000 Hello Luiz, after applying the patches, should I compile the kernel with the "device api" written into the = kernel config file? =20 thank you, f. On Aug 22, 2013, at 2:57 PM, Luiz Otavio O Souza = wrote: > Hello, >=20 > Here is a SPI driver for RPi. >=20 > It has been tested with a hardware loopback (MOSI wired to MISO) and = with a s25fl032 spansion flash (removed from a wr941nd router). >=20 > I've tested the reading from the flash up to 10Mhz of clock and = surprisingly my (simple) wiring support it without any fail. >=20 > At boot the SPI clock is set to 500Khz, not fast and not too slow (as = the 3.814Khz default): >=20 > # dd if=3D/dev/flash/spi0 of=3Dflash-wr941nd-2 bs=3D64k > 64+0 records in > 64+0 records out > 4194304 bytes transferred in 75.632316 secs (55457 bytes/sec) > # diff flash-wr941nd flash-wr941nd-2 > # sysctl dev.spi.0.clock=3D1000000 > dev.spi.0.clock: 500000 -> 1000000 > # dd if=3D/dev/flash/spi0 of=3Dflash-wr941nd-2 bs=3D64k > 64+0 records in > 64+0 records out > 4194304 bytes transferred in 37.896805 secs (110677 bytes/sec) > # diff flash-wr941nd flash-wr941nd-2 =20 > # sysctl dev.spi.0.clock=3D2000000 =20 > dev.spi.0.clock: 1000000 -> 2016129 > # dd if=3D/dev/flash/spi0 of=3Dflash-wr941nd-2 bs=3D64k > 64+0 records in > 64+0 records out > 4194304 bytes transferred in 18.879980 secs (222156 bytes/sec) > # diff flash-wr941nd flash-wr941nd-2 =20 > # sysctl dev.spi.0.clock=3D4000000 =20 > dev.spi.0.clock: 2016129 -> 4032258 > # dd if=3D/dev/flash/spi0 of=3Dflash-wr941nd-2 bs=3D64k > 64+0 records in > 64+0 records out > 4194304 bytes transferred in 9.642490 secs (434981 bytes/sec) > # diff flash-wr941nd flash-wr941nd-2 =20 > # sysctl dev.spi.0.clock=3D10000000 =20 > dev.spi.0.clock: 4032258 -> 10416666 > # dd if=3D/dev/flash/spi0 of=3Dflash-wr941nd-2 bs=3D64k > 64+0 records in > 64+0 records out > 4194304 bytes transferred in 4.317743 secs (971411 bytes/sec) > # diff flash-wr941nd flash-wr941nd-2 =20 >=20 >=20 > It export a few handy sysctl knobs: >=20 > # sysctl dev.spi > dev.spi.0.%desc: BCM2708/2835 SPI controller > dev.spi.0.%driver: spi > dev.spi.0.%parent: simplebus0 > dev.spi.0.clock: 500000 > dev.spi.0.cpol: 0 > dev.spi.0.cpha: 0 > dev.spi.0.cspol0: 0 > dev.spi.0.cspol1: 0 >=20 >=20 > About the patches: >=20 > - bcm2835_spi.diff implements the SPI driver, the dts and kernel = changes; >=20 > - ofw_spibus.diff adds the OFW SPI bus glue to attach the SPI children = as described in the FDT. >=20 > - mx25l-fdt-intr.diff adds the support for FDT and configure a intr = hook so the device identification runs only when the interrupts are = active (the SPI driver is interrupt based); >=20 > - rpi-mx25l-dts.diff the change i did to add my mx25l on the rpi dts = (only as reference). >=20 >=20 > Luiz >=20 >=20 >=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" From owner-freebsd-arm@FreeBSD.ORG Sun Aug 25 14:14: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 E0F43746 for ; Sun, 25 Aug 2013 14:14:04 +0000 (UTC) (envelope-from fabiodive@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 742112F83 for ; Sun, 25 Aug 2013 14:14:04 +0000 (UTC) Received: by mail-ee0-f47.google.com with SMTP id d49so1114041eek.6 for ; Sun, 25 Aug 2013 07:14:01 -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=t8/2snbkfGvBS9o9SYl7A9j3StsDuMvffOXat4HBZKs=; b=zg34gx5nyVcFPQmYaecoH0HClwAnT2eQNCSwkY05G860GvoPwfB+xQ41gMD2d3mnOy EUEAUSqUurUYpF06RMglIaXA1ryNKtI8UCYBCE+OnhbwwWKAiX8HqUv06QGa/IRWFQts UMpKM8+iI0+xK/Mx3qDWUmxImqLqBH4DBXP7WRaRketMJ6kutFceoMqJemTWAkrlxMj5 oNKuQ5O4t1eNgcW5P5Yl08QYL1dgRNCi+brp9507FmmQ+ydbXTdgzrtFUYMrgmxr4NZp j2qYkMfrpssyhMZry+FCZIIML/Zzmgu6c2sGSQg/xQ3lpIZmL4SWL3nqGSFRYkT/R35B 7mvA== X-Received: by 10.14.88.65 with SMTP id z41mr17007753eee.38.1377440041083; Sun, 25 Aug 2013 07:14:01 -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 z12sm14267281eev.6.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 25 Aug 2013 07:14:00 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Subject: Re: SPI driver for RPi From: fabiodive In-Reply-To: <126AAEEA-1F99-42E4-9620-9CB4F3610671@gmail.com> Date: Sun, 25 Aug 2013 15:13:58 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <8EC76E61-99BF-40E6-A39F-3E03FBDC1F30@gmail.com> References: <126AAEEA-1F99-42E4-9620-9CB4F3610671@gmail.com> To: Luiz Otavio O Souza X-Mailer: Apple Mail (2.1508) Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Aug 2013 14:14:05 -0000 pardon=85the autocorrector=85 should I use "device spi"=20 thank you f. On Aug 22, 2013, at 2:57 PM, Luiz Otavio O Souza = wrote: > Hello, >=20 > Here is a SPI driver for RPi. >=20 > It has been tested with a hardware loopback (MOSI wired to MISO) and = with a s25fl032 spansion flash (removed from a wr941nd router). >=20 > I've tested the reading from the flash up to 10Mhz of clock and = surprisingly my (simple) wiring support it without any fail. >=20 > At boot the SPI clock is set to 500Khz, not fast and not too slow (as = the 3.814Khz default): >=20 > # dd if=3D/dev/flash/spi0 of=3Dflash-wr941nd-2 bs=3D64k > 64+0 records in > 64+0 records out > 4194304 bytes transferred in 75.632316 secs (55457 bytes/sec) > # diff flash-wr941nd flash-wr941nd-2 > # sysctl dev.spi.0.clock=3D1000000 > dev.spi.0.clock: 500000 -> 1000000 > # dd if=3D/dev/flash/spi0 of=3Dflash-wr941nd-2 bs=3D64k > 64+0 records in > 64+0 records out > 4194304 bytes transferred in 37.896805 secs (110677 bytes/sec) > # diff flash-wr941nd flash-wr941nd-2 =20 > # sysctl dev.spi.0.clock=3D2000000 =20 > dev.spi.0.clock: 1000000 -> 2016129 > # dd if=3D/dev/flash/spi0 of=3Dflash-wr941nd-2 bs=3D64k > 64+0 records in > 64+0 records out > 4194304 bytes transferred in 18.879980 secs (222156 bytes/sec) > # diff flash-wr941nd flash-wr941nd-2 =20 > # sysctl dev.spi.0.clock=3D4000000 =20 > dev.spi.0.clock: 2016129 -> 4032258 > # dd if=3D/dev/flash/spi0 of=3Dflash-wr941nd-2 bs=3D64k > 64+0 records in > 64+0 records out > 4194304 bytes transferred in 9.642490 secs (434981 bytes/sec) > # diff flash-wr941nd flash-wr941nd-2 =20 > # sysctl dev.spi.0.clock=3D10000000 =20 > dev.spi.0.clock: 4032258 -> 10416666 > # dd if=3D/dev/flash/spi0 of=3Dflash-wr941nd-2 bs=3D64k > 64+0 records in > 64+0 records out > 4194304 bytes transferred in 4.317743 secs (971411 bytes/sec) > # diff flash-wr941nd flash-wr941nd-2 =20 >=20 >=20 > It export a few handy sysctl knobs: >=20 > # sysctl dev.spi > dev.spi.0.%desc: BCM2708/2835 SPI controller > dev.spi.0.%driver: spi > dev.spi.0.%parent: simplebus0 > dev.spi.0.clock: 500000 > dev.spi.0.cpol: 0 > dev.spi.0.cpha: 0 > dev.spi.0.cspol0: 0 > dev.spi.0.cspol1: 0 >=20 >=20 > About the patches: >=20 > - bcm2835_spi.diff implements the SPI driver, the dts and kernel = changes; >=20 > - ofw_spibus.diff adds the OFW SPI bus glue to attach the SPI children = as described in the FDT. >=20 > - mx25l-fdt-intr.diff adds the support for FDT and configure a intr = hook so the device identification runs only when the interrupts are = active (the SPI driver is interrupt based); >=20 > - rpi-mx25l-dts.diff the change i did to add my mx25l on the rpi dts = (only as reference). >=20 >=20 > Luiz >=20 >=20 >=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" From owner-freebsd-arm@FreeBSD.ORG Sun Aug 25 15:27: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 DC491AE8 for ; Sun, 25 Aug 2013 15:27:18 +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 B8FE82343 for ; Sun, 25 Aug 2013 15:27:17 +0000 (UTC) Received: (from root@localhost) by monday.kientzle.com (8.14.4/8.14.4) id r7PFRGYk016084; Sun, 25 Aug 2013 15:27:16 GMT (envelope-from tim@kientzle.com) Received: from [192.168.2.123] (CiscoE3000 [192.168.1.65]) by kientzle.com with SMTP id kyzxqyi4sz8n8dxpt6nuvbwbz2; Sun, 25 Aug 2013 15:27:16 +0000 (UTC) (envelope-from tim@kientzle.com) Subject: Re: Pretty good RPi version? Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Tim Kientzle In-Reply-To: Date: Sun, 25 Aug 2013 08:27:12 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5218FBE2.2000907@m5p.com> To: Jia-Shiun Li X-Mailer: Apple Mail (2.1283) 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, 25 Aug 2013 15:27:18 -0000 On Aug 25, 2013, at 12:55 AM, Jia-Shiun Li wrote: > On Sun, Aug 25, 2013 at 2:30 AM, George Mitchell = wrote: >> What's a pretty good recent Raspberry Pi svn checkout version? = 254544 >> doesn't seem to be it -- it crashes as soon as I try to make install = in >> /usr/ports/ports-mgmt/pkg. Although I'm tempted to grab one of the >> prebuilt images at http://www.db.net/downloads/, I'll have to be = doing >> some recompiling for debug purposes. I see that latest couple of >> versions there are 252209 and 250580. Are those pretty good? (By >> "pretty good", I mean capable of running a light load in a fairly >> stable way over a period of days.) Thanks for your help! -- George >=20 > I got the same question. I was trying to update RPi this week, but > several attempts has failed. RPi would hang at high load like > "portsnap fetch extract" or "cd /usr/ports/graphics/graphviz && make > install clean". By "hang" I mean ssh session and console had no > response. But it still replies to ICMP and TCP connection handshake > requests. Looks like something got stuck in the kernel. Do you have a serial console? If so, is it still responsive there? I've been seeing a similar problem on BB. In those cases, typing a key on the serial console unblocks it. Tim From owner-freebsd-arm@FreeBSD.ORG Sun Aug 25 15:35: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 9B640F42; Sun, 25 Aug 2013 15:35:00 +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 763D523B1; Sun, 25 Aug 2013 15:35:00 +0000 (UTC) Received: (from root@localhost) by monday.kientzle.com (8.14.4/8.14.4) id r7PFYxs4016160; Sun, 25 Aug 2013 15:34:59 GMT (envelope-from tim@kientzle.com) Received: from [192.168.2.123] (CiscoE3000 [192.168.1.65]) by kientzle.com with SMTP id fti3xtthx68d6t7xnbbradebai; Sun, 25 Aug 2013 15:34:59 +0000 (UTC) (envelope-from tim@kientzle.com) Subject: Re: Pretty good RPi version? Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Tim Kientzle In-Reply-To: Date: Sun, 25 Aug 2013 08:34:59 -0700 Content-Transfer-Encoding: 7bit Message-Id: References: <5218FBE2.2000907@m5p.com> <20130825.195532.59669686.shigeru@os-hackers.jp> To: freebsd-arm@freebsd.org 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: Sun, 25 Aug 2013 15:35:00 -0000 On Aug 25, 2013, at 5:07 AM, Adrian Chadd wrote: > Hi! > > All - if it's unstable, please complain loudly on -arm and -current and > file PRs. If you have the time, please help figure out which commit(s) > broke things. > > There's been plenty of "stuff is unstable" talk, but I'm not sure it's > percolated its way up to the people doing VM hacking on other platforms > (notably amd64) so they are likely unaware they've broken things. > > It's possible they've also broken things for MIPS, which has me worried. :( On a similar note: FreeBSD is starting the process for branching and releasing FreeBSD 10.0. (The whole process will take a few months, but it means we need to get bugs isolated and fixed NOW.) I would *love* to have a solid, stable FreeBSD/ARM for 10.0. (If nothing else, I started tinkering with BeagleBone in late 2011 specifically so I could move my personal email server onto one. ;-) To get there, we need as many people as possible: * Running the bleeding edge FreeBSD. * Reporting problems. * Helping to diagnose those problems. Q: Does anyone know a good way to test userland locking? Diane Bruce has been continuing to dig into the issue that broke sshd a while back; the clues point to some issue in jemalloc (possibly locking related?). Q: Has anyone tried running some or all of the FreeBSD regression tests? Tim From owner-freebsd-arm@FreeBSD.ORG Sun Aug 25 15:58:22 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 E88DA62B for ; Sun, 25 Aug 2013 15:58:21 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-ie0-f169.google.com (mail-ie0-f169.google.com [209.85.223.169]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id B5E8424C3 for ; Sun, 25 Aug 2013 15:58:21 +0000 (UTC) Received: by mail-ie0-f169.google.com with SMTP id 10so3696121ied.0 for ; Sun, 25 Aug 2013 08:58:15 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; 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=qZE3gLuV2ZtYaHZvYncgkHd+ysewpIMCR1Wy/kvAlDM=; b=fU3fFJ8hGoi52l0ujWy1FegUhZKvfR2O+5riff/WYrK4jL5pXlLCgxLcYD748qEkPw FLNu3AQx8qOZQ/yXcoyadYlbnJV7+G+2xcn65D86cHJmQKipHDhX65mz5ROxyBlESHgn N+YUg46/tMI6LmOa10IhtyLDWX6wWcw76ZDqq40Iy7M41eoagy4xieSKXEWzEngOPo5Z 6UpDJW8SaryjPl5E8MQnP+Aol4QGnX/0/YJkb/Mqxz/kgFdVQvIBbjqD0Vn8PjAqtBOB A+wk1gDBgfr/lm4hpyT1ZJ0KH0grZhikfXwFrRXt6uuvAKsV87E3lLhqdGEM9D2zwXt1 YU8g== X-Gm-Message-State: ALoCoQlxSLN8Pll5u4pjuKIJKdqVJcy3RUg9XLQIKmt1ZVlx64gMZXgHcfbT4G8eDWAwd55GSJfc X-Received: by 10.42.12.8 with SMTP id w8mr1467415icw.1.1377446295654; Sun, 25 Aug 2013 08:58:15 -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 yt10sm11574010igb.9.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 25 Aug 2013 08:58:14 -0700 (PDT) Sender: Warner Losh Subject: Re: Pretty good RPi version? Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: Date: Sun, 25 Aug 2013 09:58:12 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <2DF35AA8-01C3-4F99-848A-34BD52EA5193@bsdimp.com> References: <5218FBE2.2000907@m5p.com> <20130825.195532.59669686.shigeru@os-hackers.jp> To: Tim Kientzle X-Mailer: Apple Mail (2.1085) Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Aug 2013 15:58:22 -0000 On Aug 25, 2013, at 9:34 AM, Tim Kientzle wrote: >=20 > On Aug 25, 2013, at 5:07 AM, Adrian Chadd wrote: >=20 >> Hi! >>=20 >> All - if it's unstable, please complain loudly on -arm and -current = and >> file PRs. If you have the time, please help figure out which = commit(s) >> broke things. >>=20 >> There's been plenty of "stuff is unstable" talk, but I'm not sure = it's >> percolated its way up to the people doing VM hacking on other = platforms >> (notably amd64) so they are likely unaware they've broken things. >>=20 >> It's possible they've also broken things for MIPS, which has me = worried. :( >=20 > On a similar note: FreeBSD is starting the process for branching > and releasing FreeBSD 10.0. (The whole process will take a few > months, but it means we need to get bugs isolated and fixed NOW.) >=20 > I would *love* to have a solid, stable FreeBSD/ARM for 10.0. > (If nothing else, I started tinkering with BeagleBone in late 2011 > specifically so I could move my personal email server onto one. ;-) >=20 > To get there, we need as many people as possible: > * Running the bleeding edge FreeBSD. > * Reporting problems. > * Helping to diagnose those problems. >=20 > Q: Does anyone know a good way to test userland locking? >=20 > Diane Bruce has been continuing to dig into the issue that > broke sshd a while back; the clues point to some issue in > jemalloc (possibly locking related?). Once upon a time, back in the RAS/armv4 days, I found a bug. Locks were = getting stuck in threads in my employer's command and control program. = After much debugging, it came down to the atomic operations implemented = by RAS were less than atomic. There was a one or two instruction race in = them. Usually they'd work, and you needed a very high interrupt load, = like in my employer's hardware, to see the problem reliably. It would be = useful to eliminate this possibility, even though RAS is off the table = for armv6, this is really the first release with armv6 support and the = atomics haven't been through the torture test of that process yet. Warner > Q: Has anyone tried running some or all of the FreeBSD > regression tests? >=20 > Tim >=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" From owner-freebsd-arm@FreeBSD.ORG Sun Aug 25 16:03: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 850AB6AE for ; Sun, 25 Aug 2013 16:03:31 +0000 (UTC) (envelope-from zbb@semihalf.com) Received: from mail-qa0-f43.google.com (mail-qa0-f43.google.com [209.85.216.43]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 446BC2512 for ; Sun, 25 Aug 2013 16:03:30 +0000 (UTC) Received: by mail-qa0-f43.google.com with SMTP id bq6so397500qab.9 for ; Sun, 25 Aug 2013 09:03:24 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=TWvz5R9te/9ivKIHiYmGgsnlRostyk7VsA1zq8brJEs=; b=hsH7gnPQeFAwk7M7lcbuckQIsDb9rWEUFCMGbwPnUY+SLuHoXLZOB72O8H8xerUv5E iMeDk3SNtIykQ08O2n4LQLxTcvzv2sRE+/p4iYMBj8VP8PhoNlceYNVlF43VCla8cp9O 2ctO4n5M6/vxpsdcBYW2CwAGJoN6Qi/CUi3EI/J6OAjnUVPTzQe0WHDPCEpL70ETbHzI /pC8a0sdxWpQGEFeN+MvEtAvfD81oZ1Md0BvlUbbel8kkmVW74Z6m/njeFe+9yd8c23c Dv5cAMp1CrqZm4nF+d06W1ZW8EavlMOfnagP9GBiu/KOSnHCZG6UZT4NacBFJ2R95gxJ 0aYg== X-Gm-Message-State: ALoCoQmmbaLmcxL8vJjQclpAkicpZ2NIF4sc0tf0IQPit0tdU1s3vXBx0cnZttqdvFjr3Z0OaQEx MIME-Version: 1.0 X-Received: by 10.224.63.72 with SMTP id a8mr3950533qai.72.1377446604308; Sun, 25 Aug 2013 09:03:24 -0700 (PDT) Received: by 10.49.8.20 with HTTP; Sun, 25 Aug 2013 09:03:24 -0700 (PDT) In-Reply-To: <2DF35AA8-01C3-4F99-848A-34BD52EA5193@bsdimp.com> References: <5218FBE2.2000907@m5p.com> <20130825.195532.59669686.shigeru@os-hackers.jp> <2DF35AA8-01C3-4F99-848A-34BD52EA5193@bsdimp.com> Date: Sun, 25 Aug 2013 18:03:24 +0200 Message-ID: Subject: Re: Pretty good RPi version? From: Zbigniew Bodek To: Warner Losh Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 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, 25 Aug 2013 16:03:31 -0000 2013/8/25 Warner Losh > > On Aug 25, 2013, at 9:34 AM, Tim Kientzle wrote: > > > > > On Aug 25, 2013, at 5:07 AM, Adrian Chadd wrote: > > > >> Hi! > >> > >> All - if it's unstable, please complain loudly on -arm and -current and > >> file PRs. If you have the time, please help figure out which commit(s) > >> broke things. > >> > >> There's been plenty of "stuff is unstable" talk, but I'm not sure it's > >> percolated its way up to the people doing VM hacking on other platforms > >> (notably amd64) so they are likely unaware they've broken things. > >> > >> It's possible they've also broken things for MIPS, which has me > worried. :( > > > > On a similar note: FreeBSD is starting the process for branching > > and releasing FreeBSD 10.0. (The whole process will take a few > > months, but it means we need to get bugs isolated and fixed NOW.) > > > > I would *love* to have a solid, stable FreeBSD/ARM for 10.0. > > (If nothing else, I started tinkering with BeagleBone in late 2011 > > specifically so I could move my personal email server onto one. ;-) > > > > To get there, we need as many people as possible: > > * Running the bleeding edge FreeBSD. > > * Reporting problems. > > * Helping to diagnose those problems. > > > > Q: Does anyone know a good way to test userland locking? > > > > Diane Bruce has been continuing to dig into the issue that > > broke sshd a while back; the clues point to some issue in > > jemalloc (possibly locking related?). > > Once upon a time, back in the RAS/armv4 days, I found a bug. Locks were > getting stuck in threads in my employer's command and control program. > After much debugging, it came down to the atomic operations implemented by > RAS were less than atomic. There was a one or two instruction race in them. > Usually they'd work, and you needed a very high interrupt load, like in my > employer's hardware, to see the problem reliably. It would be useful to > eliminate this possibility, even though RAS is off the table for armv6, > this is really the first release with armv6 support and the atomics haven't > been through the torture test of that process yet. > > Warner > > > Q: Has anyone tried running some or all of the FreeBSD > > regression tests? > > > > Tim > > > Hello. Also please try commenting out pmap_copy() body in sys/arm/arm/pmap-v6.c There is a bug there that we are aware of so please either comment out or place return in pmap_copy() and try again with your tests. Best regards Zbyszek Bodek From owner-freebsd-arm@FreeBSD.ORG Sun Aug 25 23:00:02 2013 Return-Path: Delivered-To: freebsd-arm@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 8C911498 for ; Sun, 25 Aug 2013 23:00:02 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 5FEB92761 for ; Sun, 25 Aug 2013 23:00:02 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r7PN01ud000483 for ; Sun, 25 Aug 2013 23:00:01 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r7PN01PB000482; Sun, 25 Aug 2013 23:00:01 GMT (envelope-from gnats) Date: Sun, 25 Aug 2013 23:00:01 GMT Message-Id: <201308252300.r7PN01PB000482@freefall.freebsd.org> To: freebsd-arm@FreeBSD.org Cc: From: Andreas Schwarz Subject: Re: arm/178495: buildworld fail on arm/raspberry pi X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Andreas Schwarz List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Aug 2013 23:00:02 -0000 The following reply was made to PR arm/178495; it has been noted by GNATS. From: Andreas Schwarz To: bug-followup@FreeBSD.org Cc: Subject: Re: arm/178495: buildworld fail on arm/raspberry pi Date: Mon, 26 Aug 2013 00:53:12 +0200 (CEST) Hi, in the meantime this problem was solved, it's possible to build the world using a raspberry with the current/head freebsd base system. You can close the bug. From owner-freebsd-arm@FreeBSD.ORG Sun Aug 25 23:21:02 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id DAA4E7E5; Sun, 25 Aug 2013 23:21:02 +0000 (UTC) (envelope-from george+freebsd@m5p.com) Received: from mailhost.m5p.com (ip-2-1-0-2.r03.asbnva02.us.ce.gin.ntt.net [IPv6:2001:418:0:5000::16]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 9033C28A6; Sun, 25 Aug 2013 23:21:02 +0000 (UTC) Received: from wonderland.m5p.com (localhost [IPv6:::1]) by mailhost.m5p.com (8.14.5/8.14.5) with ESMTP id r7PNKr1A081753; Sun, 25 Aug 2013 19:20:58 -0400 (EDT) (envelope-from george+freebsd@m5p.com) Message-ID: <521A9155.5010102@m5p.com> Date: Sun, 25 Aug 2013 19:20:53 -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: Hans Petter Selasky Subject: Re: ulpt can't attach Lexmark E120 References: <5105527F.3010708@m5p.com> <201301271915.47712.hselasky@c2i.net> <510570C1.1060607@m5p.com> <201301272007.30682.hselasky@c2i.net> <5105AB16.2000607@m5p.com> <5215F4DF.6000305@m5p.com> <5215F743.8060403@bitfrost.no> <5216ACE5.7000500@m5p.com> <5216FE9F.2030608@bitfrost.no> <52174378.2020101@m5p.com> <521801E5.9000309@m5p.com> <52184F59.5080100@bitfrost.no> <5218F993.9050504@m5p.com> <5219C3FF.1070509@bitfrost.no> In-Reply-To: <5219C3FF.1070509@bitfrost.no> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.73 on 10.100.0.3 X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.7 (mailhost.m5p.com [IPv6:::1]); Sun, 25 Aug 2013 19:20:59 -0400 (EDT) Cc: freebsd-arm@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: Sun, 25 Aug 2013 23:21:02 -0000 On 08/25/13 04:44, Hans Petter Selasky wrote: > On 08/24/13 20:21, George Mitchell wrote: >> >> Setting hw.usb.dwc_otg.debug to any value greater than 0 generates an >> unending stream of debug output and effectively locks up the chip >> scrolling the output on the display. Perhaps there are some specific >> debug messages I could put in ... -- George > > Hi, > > Can you try this patch: > > http://svnweb.freebsd.org/changeset/base/254828 > > --HPS > _______________________________________________ > [...] I started trying to do too many things at once, and as a result it's going to take me a little while to try this patch out. My apologies! -- George From owner-freebsd-arm@FreeBSD.ORG Mon Aug 26 02:50:00 2013 Return-Path: Delivered-To: freebsd-arm@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id A3E7E330 for ; Mon, 26 Aug 2013 02:50:00 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 8271B2218 for ; Mon, 26 Aug 2013 02:50:00 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r7Q2o0vx053481 for ; Mon, 26 Aug 2013 02:50:00 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r7Q2o0XO053480; Mon, 26 Aug 2013 02:50:00 GMT (envelope-from gnats) Resent-Date: Mon, 26 Aug 2013 02:50:00 GMT Resent-Message-Id: <201308260250.r7Q2o0XO053480@freefall.freebsd.org> Resent-From: FreeBSD-gnats-submit@FreeBSD.org (GNATS Filer) Resent-To: freebsd-arm@FreeBSD.org Resent-Reply-To: FreeBSD-gnats-submit@FreeBSD.org, ksMjiPHMd 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 4F62B2FF for ; Mon, 26 Aug 2013 02:45:08 +0000 (UTC) (envelope-from nobody@FreeBSD.org) Received: from oldred.freebsd.org (oldred.freebsd.org [8.8.178.121]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 3C6C42203 for ; Mon, 26 Aug 2013 02:45:08 +0000 (UTC) Received: from oldred.freebsd.org ([127.0.1.6]) by oldred.freebsd.org (8.14.5/8.14.7) with ESMTP id r7Q2j71c095094 for ; Mon, 26 Aug 2013 02:45:07 GMT (envelope-from nobody@oldred.freebsd.org) Received: (from nobody@localhost) by oldred.freebsd.org (8.14.5/8.14.5/Submit) id r7Q2j7R0095093; Mon, 26 Aug 2013 02:45:07 GMT (envelope-from nobody) Message-Id: <201308260245.r7Q2j7R0095093@oldred.freebsd.org> Date: Mon, 26 Aug 2013 02:45:07 GMT From: ksMjiPHMd To: freebsd-gnats-submit@FreeBSD.org X-Send-Pr-Version: www-3.1 Subject: arm/181535: uDEmA2W70s 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, 26 Aug 2013 02:50:00 -0000 >Number: 181535 >Category: arm >Synopsis: uDEmA2W70s >Confidential: no >Severity: non-critical >Priority: low >Responsible: freebsd-arm >State: open >Quarter: >Keywords: >Date-Required: >Class: maintainer-update >Submitter-Id: current-users >Arrival-Date: Mon Aug 26 02:50:00 UTC 2013 >Closed-Date: >Last-Modified: >Originator: ksMjiPHMd >Release: 8FFRCDwft1 >Organization: P7yt6Zpg >Environment: Als ich vor ca. 1 Jahr mein Studium beendete und in das Berufsleben etseiing, waren meine Unterlagen noch ziemlich durcheinander. Ich hatte weder einen dcberblick fcber meine vor Jahren abgeschlossenen Sparvertre4ge, noch hatte ich Versicherungen, die zu meinem neuen Lebensabschnitt passten. Zuse4tzlich dazu hatte ich einen hohen Kredit mit fcberzogenen Gebfchren, den ich ziemlich ahnungslos und uninformiert ffcr mein Studium abgeschlossen hatte. Herr Steinberger zeigte unheimlich viel Geduld und Einsatzbereitschaft, meine Unterlagen zu durchforsten, mir ein individuelles Konzept mit passenden Versicherungs- und Sparvertre4gen zu erstellen und, vor allem, mir alles verste4ndlich und genau zu erkle4ren. Schliedflich hat er es sogar geschafft, meinen teuren Kredit umzuschulden und mir so ermf6glicht, schneller schuldenfrei zu sein. Herr Steinberger ist dabei jederzeit ffcr meine Fragen erreichbar und nimmt sich wie selbstverste4ndlich die Zeit, Rfcckfragen an Gesellschaft en ffcr mich zu kle4ren, um Missverste4ndnisse gar nicht erst aufkommen zu lassen. So kann ich sicher sein, dass Fehler gar nicht erst entstehen.Zur Zeit bin ich beruflich in San Francisco. Da es auf das Jahresende zugeht, fcberprfcft Herr Steinberger auch fcber die Entfernung hinweg notwendige c4nderungen in meinen Vertre4gen und koordiniert die Kommunikation mit den Gesellschaften. Daffcr bin ich besonders dankbar, da ich durch den Zeitunterschied und die eingeschre4nkte Erreichbarkeit Schwierigkeiten he4tte, die c4nderungen alleine zu organisieren.Ich bin sehr froh, dass ich einen so kompetenten Berater gleich zu Beginn meines Berufslebens habe, und kann ihn mit bestem Gewissen weiterempfehlen. >Description: Als ich vor ca. 1 Jahr mein Studium beendete und in das Berufsleben etseiing, waren meine Unterlagen noch ziemlich durcheinander. Ich hatte weder einen dcberblick fcber meine vor Jahren abgeschlossenen Sparvertre4ge, noch hatte ich Versicherungen, die zu meinem neuen Lebensabschnitt passten. Zuse4tzlich dazu hatte ich einen hohen Kredit mit fcberzogenen Gebfchren, den ich ziemlich ahnungslos und uninformiert ffcr mein Studium abgeschlossen hatte. Herr Steinberger zeigte unheimlich viel Geduld und Einsatzbereitschaft, meine Unterlagen zu durchforsten, mir ein individuelles Konzept mit passenden Versicherungs- und Sparvertre4gen zu erstellen und, vor allem, mir alles verste4ndlich und genau zu erkle4ren. Schliedflich hat er es sogar geschafft, meinen teuren Kredit umzuschulden und mir so ermf6glicht, schneller schuldenfrei zu sein. Herr Steinberger ist dabei jederzeit ffcr meine Fragen erreichbar und nimmt sich wie selbstverste4ndlich die Zeit, Rfcckfragen an Gesellschaften ffcr mich z u kle4ren, um Missverste4ndnisse gar nicht erst aufkommen zu lassen. So kann ich sicher sein, dass Fehler gar nicht erst entstehen.Zur Zeit bin ich beruflich in San Francisco. Da es auf das Jahresende zugeht, fcberprfcft Herr Steinberger auch fcber die Entfernung hinweg notwendige c4nderungen in meinen Vertre4gen und koordiniert die Kommunikation mit den Gesellschaften. Daffcr bin ich besonders dankbar, da ich durch den Zeitunterschied und die eingeschre4nkte Erreichbarkeit Schwierigkeiten he4tte, die c4nderungen alleine zu organisieren.Ich bin sehr froh, dass ich einen so kompetenten Berater gleich zu Beginn meines Berufslebens habe, und kann ihn mit bestem Gewissen weiterempfehlen. >How-To-Repeat: Als ich vor ca. 1 Jahr mein Studium beendete und in das Berufsleben etseiing, waren meine Unterlagen noch ziemlich durcheinander. Ich hatte weder einen dcberblick fcber meine vor Jahren abgeschlossenen Sparvertre4ge, noch hatte ich Versicherungen, die zu meinem neuen Lebensabschnitt passten. Zuse4tzlich dazu hatte ich einen hohen Kredit mit fcberzogenen Gebfchren, den ich ziemlich ahnungslos und uninformiert ffcr mein Studium abgeschlossen hatte. Herr Steinberger zeigte unheimlich viel Geduld und Einsatzbereitschaft, meine Unterlagen zu durchforsten, mir ein individuelles Konzept mit passenden Versicherungs- und Sparvertre4gen zu erstellen und, vor allem, mir alles verste4ndlich und genau zu erkle4ren. Schliedflich hat er es sogar geschafft, meinen teuren Kredit umzuschulden und mir so ermf6glicht, schneller schuldenfrei zu sein. Herr Steinberger ist dabei jederzeit ffcr meine Fragen erreichbar und nimmt sich wie selbstverste4ndlich die Zeit, Rfcckfragen an Gesellschaften ffcr mich z u kle4ren, um Missverste4ndnisse gar nicht erst aufkommen zu lassen. So kann ich sicher sein, dass Fehler gar nicht erst entstehen.Zur Zeit bin ich beruflich in San Francisco. Da es auf das Jahresende zugeht, fcberprfcft Herr Steinberger auch fcber die Entfernung hinweg notwendige c4nderungen in meinen Vertre4gen und koordiniert die Kommunikation mit den Gesellschaften. Daffcr bin ich besonders dankbar, da ich durch den Zeitunterschied und die eingeschre4nkte Erreichbarkeit Schwierigkeiten he4tte, die c4nderungen alleine zu organisieren.Ich bin sehr froh, dass ich einen so kompetenten Berater gleich zu Beginn meines Berufslebens habe, und kann ihn mit bestem Gewissen weiterempfehlen. >Fix: Als ich vor ca. 1 Jahr mein Studium beendete und in das Berufsleben etseiing, waren meine Unterlagen noch ziemlich durcheinander. Ich hatte weder einen dcberblick fcber meine vor Jahren abgeschlossenen Sparvertre4ge, noch hatte ich Versicherungen, die zu meinem neuen Lebensabschnitt passten. Zuse4tzlich dazu hatte ich einen hohen Kredit mit fcberzogenen Gebfchren, den ich ziemlich ahnungslos und uninformiert ffcr mein Studium abgeschlossen hatte. Herr Steinberger zeigte unheimlich viel Geduld und Einsatzbereitschaft, meine Unterlagen zu durchforsten, mir ein individuelles Konzept mit passenden Versicherungs- und Sparvertre4gen zu erstellen und, vor allem, mir alles verste4ndlich und genau zu erkle4ren. Schliedflich hat er es sogar geschafft, meinen teuren Kredit umzuschulden und mir so ermf6glicht, schneller schuldenfrei zu sein. Herr Steinberger ist dabei jederzeit ffcr meine Fragen erreichbar und nimmt sich wie selbstverste4ndlich die Zeit, Rfcckfragen an Gesellschaften ffcr mich z u kle4ren, um Missverste4ndnisse gar nicht erst aufkommen zu lassen. So kann ich sicher sein, dass Fehler gar nicht erst entstehen.Zur Zeit bin ich beruflich in San Francisco. Da es auf das Jahresende zugeht, fcberprfcft Herr Steinberger auch fcber die Entfernung hinweg notwendige c4nderungen in meinen Vertre4gen und koordiniert die Kommunikation mit den Gesellschaften. Daffcr bin ich besonders dankbar, da ich durch den Zeitunterschied und die eingeschre4nkte Erreichbarkeit Schwierigkeiten he4tte, die c4nderungen alleine zu organisieren.Ich bin sehr froh, dass ich einen so kompetenten Berater gleich zu Beginn meines Berufslebens habe, und kann ihn mit bestem Gewissen weiterempfehlen. >Release-Note: >Audit-Trail: >Unformatted: From owner-freebsd-arm@FreeBSD.ORG Mon Aug 26 06:22:09 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id AA3A9B59 for ; Mon, 26 Aug 2013 06:22:09 +0000 (UTC) (envelope-from jiashiun@gmail.com) Received: from mail-oa0-x231.google.com (mail-oa0-x231.google.com [IPv6:2607:f8b0:4003:c02::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 776F42B3E for ; Mon, 26 Aug 2013 06:22:09 +0000 (UTC) Received: by mail-oa0-f49.google.com with SMTP id n12so929723oag.8 for ; Sun, 25 Aug 2013 23:22:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=P0BNlfLTYzfsuiTpeuz3HiPpyDHgCwWiWPV3dYgn4NM=; b=FFRolNAppEn/d1hLG68pzOLdXm3ig1ppglyWRDVOMtIYTDFwoA/B0ipW/ebD9/A9qX Tkl8QH5Tya7r8UecOk+tYeblGbGcYXl9fCDexzeUMLOIwhAMfUMIoNBmfMZXEH622zzw m06Cj6eAv62Nh898TFuZzM6BAb3SWEKKw7qm1WQgoRwiyIbymeBS3bAFayDVVv4vrzGO 1Iw5FcaL/xSb+ABNC9eZhyYpaT5mElWQg3+/LMPLOhutoznup70Sl2slmDL67KA21gEb XcC9DWDX4s07WdGMsBdmk27MORmbYx/t+Lo+triUzdaDHDCsnuvY6U65sTl9iSzgOusi FGEQ== X-Received: by 10.182.71.82 with SMTP id s18mr12753273obu.9.1377498128760; Sun, 25 Aug 2013 23:22:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.76.131.111 with HTTP; Sun, 25 Aug 2013 23:21:38 -0700 (PDT) In-Reply-To: References: <5218FBE2.2000907@m5p.com> From: Jia-Shiun Li Date: Mon, 26 Aug 2013 14:21:38 +0800 Message-ID: Subject: Re: Pretty good RPi version? To: Tim Kientzle Content-Type: text/plain; charset=UTF-8 Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Aug 2013 06:22:09 -0000 On Sun, Aug 25, 2013 at 11:27 PM, Tim Kientzle wrote: > Do you have a serial console? > > If so, is it still responsive there? > > I've been seeing a similar problem on BB. In those > cases, typing a key on the serial console unblocks it. Not yet, but I am getting one. Hopefully I can see then if it is the same on RPi as you mentioned. BTW, do I need to redirect console to serial, and how? RPi defaults to HDMI video. Looks like commenting 'device sc' lines in kernel conf is the way to do. Probably need another keyboard attaching to the USB port to see if the same happens on HDMI video console. I am currently using USB KVM switch. Thanks, Jia-Shiun. From owner-freebsd-arm@FreeBSD.ORG Mon Aug 26 08:34:38 2013 Return-Path: Delivered-To: freebsd-arm@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id D0DC1F34; Mon, 26 Aug 2013 08:34:38 +0000 (UTC) (envelope-from se@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 A68A023A8; Mon, 26 Aug 2013 08:34:38 +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 r7Q8YcBO035895; Mon, 26 Aug 2013 08:34:38 GMT (envelope-from se@freefall.freebsd.org) Received: (from se@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r7Q8YclR035894; Mon, 26 Aug 2013 08:34:38 GMT (envelope-from se) Date: Mon, 26 Aug 2013 08:34:38 GMT Message-Id: <201308260834.r7Q8YclR035894@freefall.freebsd.org> To: bill@votehere.net, se@FreeBSD.org, freebsd-arm@FreeBSD.org From: se@FreeBSD.org Subject: Re: arm/181535: uDEmA2W70s 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, 26 Aug 2013 08:34:38 -0000 Synopsis: uDEmA2W70s State-Changed-From-To: open->closed State-Changed-By: se State-Changed-When: Mon Aug 26 08:34:02 UTC 2013 State-Changed-Why: SPAM http://www.freebsd.org/cgi/query-pr.cgi?pr=181535 From owner-freebsd-arm@FreeBSD.ORG Mon Aug 26 08:34:54 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 7CCC76B for ; Mon, 26 Aug 2013 08:34:54 +0000 (UTC) (envelope-from jakob@alvermark.net) Received: from smtprelay-b31.telenor.se (smtprelay-b31.telenor.se [213.150.131.20]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 0EE9823B3 for ; Mon, 26 Aug 2013 08:34:53 +0000 (UTC) Received: from ipb1.telenor.se (ipb1.telenor.se [195.54.127.164]) by smtprelay-b31.telenor.se (Postfix) with ESMTP id 8C5F2C095 for ; Mon, 26 Aug 2013 10:34:51 +0200 (CEST) X-SENDER-IP: [85.229.94.62] X-LISTENER: [smtp.bredband.net] X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ais8AMUSG1JV5V4+PGdsb2JhbABagwc1skOOIIEgFwMBAQEBODWCJAEBBAE6HCMQCxguLQwKFAYTh3sKtz6QRTMHgxx9A6QmiEk X-IronPort-AV: E=Sophos;i="4.89,956,1367964000"; d="scan'208";a="607455237" Received: from c-3e5ee555.06-11-73746f31.cust.bredbandsbolaget.se (HELO sigyn.alvermark.net) ([85.229.94.62]) by ipb1.telenor.se with ESMTP; 26 Aug 2013 10:34:51 +0200 Received: from gw.inter-sonic.com ([212.247.8.97] helo=[192.168.1.191]) by sigyn.alvermark.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1VDsGA-000NoM-LY; Mon, 26 Aug 2013 10:34:50 +0200 Subject: Re: Pretty good RPi version? Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Jakob Alvermark In-Reply-To: Date: Mon, 26 Aug 2013 10:34:49 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <70652C61-98B0-40E2-BB98-B8B414E30219@alvermark.net> References: <5218FBE2.2000907@m5p.com> To: Tim Kientzle X-Mailer: Apple Mail (2.1085) Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Aug 2013 08:34:54 -0000 On 25 aug 2013, at 17:27, Tim Kientzle wrote: >=20 > On Aug 25, 2013, at 12:55 AM, Jia-Shiun Li wrote: >=20 >> On Sun, Aug 25, 2013 at 2:30 AM, George Mitchell = wrote: >>> What's a pretty good recent Raspberry Pi svn checkout version? = 254544 >>> doesn't seem to be it -- it crashes as soon as I try to make install = in >>> /usr/ports/ports-mgmt/pkg. Although I'm tempted to grab one of the >>> prebuilt images at http://www.db.net/downloads/, I'll have to be = doing >>> some recompiling for debug purposes. I see that latest couple of >>> versions there are 252209 and 250580. Are those pretty good? (By >>> "pretty good", I mean capable of running a light load in a fairly >>> stable way over a period of days.) Thanks for your help! -- = George >>=20 >> I got the same question. I was trying to update RPi this week, but >> several attempts has failed. RPi would hang at high load like >> "portsnap fetch extract" or "cd /usr/ports/graphics/graphviz && make >> install clean". By "hang" I mean ssh session and console had no >> response. But it still replies to ICMP and TCP connection handshake >> requests. Looks like something got stuck in the kernel. >=20 > Do you have a serial console? >=20 > If so, is it still responsive there? >=20 > I've been seeing a similar problem on BB. In those > cases, typing a key on the serial console unblocks it. Hi, I see something similar on my Allwinner A13 (Olimex board) Running 'portsnap fetch' hangs after a while. Serial console is dead as well! A13 support is not in the tree, but it is very similar to the A10 = (Cubieboard). I have some local patches, which I intend to send to = someone for review (Tim? Ganbold?) I just need to get around to clean them up a bit first. Jakob= From owner-freebsd-arm@FreeBSD.ORG Mon Aug 26 10:17:57 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 DF7D356B for ; Mon, 26 Aug 2013 10:17:57 +0000 (UTC) (envelope-from ganbold@gmail.com) Received: from mail-pa0-x22c.google.com (mail-pa0-x22c.google.com [IPv6:2607:f8b0:400e:c03::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id B83D2215B for ; Mon, 26 Aug 2013 10:17:57 +0000 (UTC) Received: by mail-pa0-f44.google.com with SMTP id fz6so3255571pac.31 for ; Mon, 26 Aug 2013 03:17: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=c9UqrpK9OXAYIT84N8QZBAnU8WyWx6llH03AVF4tzEE=; b=nZaYBzQ6TTy142W5SwY+6g8DERCb9YYBg4kLcXblEETV0EKEVy5u3KLkvHvMWguBWg yItGA56PVeqlmzUo/Be8OGh1OnggkJzlK8j6FMa1ez3LGEjsMvPjmZ+dKY7/H8b7cl8e AKPUZVHjldu+WJFBqD9n8rc43ycUssBHW1CjcvqTgKdySAWoDLOJrY2TORRXpHVvQvgi cg2TRgT1/ZsTffrhqizd8UbdUr5F/nFPniB4T5C/UOKLta2LVDG0IGvf99T5F8D13WGH mPcMnf8Lbmq57Qsr99myGQQm+MlsmIf9s+cw+InQlUFWOxBI9m/rBoSg6s+Ge+aR000s W2YA== MIME-Version: 1.0 X-Received: by 10.68.210.103 with SMTP id mt7mr1970436pbc.179.1377512277311; Mon, 26 Aug 2013 03:17:57 -0700 (PDT) Received: by 10.68.88.129 with HTTP; Mon, 26 Aug 2013 03:17:57 -0700 (PDT) In-Reply-To: <70652C61-98B0-40E2-BB98-B8B414E30219@alvermark.net> References: <5218FBE2.2000907@m5p.com> <70652C61-98B0-40E2-BB98-B8B414E30219@alvermark.net> Date: Mon, 26 Aug 2013 18:17:57 +0800 Message-ID: Subject: Re: Pretty good RPi version? From: Ganbold Tsagaankhuu To: Jakob Alvermark Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 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: Mon, 26 Aug 2013 10:17:57 -0000 On Mon, Aug 26, 2013 at 4:34 PM, Jakob Alvermark wrote: > On 25 aug 2013, at 17:27, Tim Kientzle wrote: > > > > > On Aug 25, 2013, at 12:55 AM, Jia-Shiun Li wrote: > > > >> On Sun, Aug 25, 2013 at 2:30 AM, George Mitchell < > george+freebsd@m5p.com> wrote: > >>> What's a pretty good recent Raspberry Pi svn checkout version? 254544 > >>> doesn't seem to be it -- it crashes as soon as I try to make install in > >>> /usr/ports/ports-mgmt/pkg. Although I'm tempted to grab one of the > >>> prebuilt images at http://www.db.net/downloads/, I'll have to be doing > >>> some recompiling for debug purposes. I see that latest couple of > >>> versions there are 252209 and 250580. Are those pretty good? (By > >>> "pretty good", I mean capable of running a light load in a fairly > >>> stable way over a period of days.) Thanks for your help! -- George > >> > >> I got the same question. I was trying to update RPi this week, but > >> several attempts has failed. RPi would hang at high load like > >> "portsnap fetch extract" or "cd /usr/ports/graphics/graphviz && make > >> install clean". By "hang" I mean ssh session and console had no > >> response. But it still replies to ICMP and TCP connection handshake > >> requests. Looks like something got stuck in the kernel. > > > > Do you have a serial console? > > > > If so, is it still responsive there? > > > > I've been seeing a similar problem on BB. In those > > cases, typing a key on the serial console unblocks it. > > Hi, I see something similar on my Allwinner A13 (Olimex board) > > Running 'portsnap fetch' hangs after a while. > > Serial console is dead as well! > > A13 support is not in the tree, but it is very similar to the A10 > (Cubieboard). I have some local patches, which I intend to send to someone > for review (Tim? Ganbold?) > In my case I asked gonzo@ and ray@ to review A10/A20 related changes. Ganbold > I just need to get around to clean them up a bit first. > > Jakob > _______________________________________________ > 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 Mon Aug 26 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 5E7869E for ; Mon, 26 Aug 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 309FF2852 for ; Mon, 26 Aug 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 r7QB6fYC065866 for ; Mon, 26 Aug 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 r7QB6eDN065864 for freebsd-arm@FreeBSD.org; Mon, 26 Aug 2013 11:06:40 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 26 Aug 2013 11:06:40 GMT Message-Id: <201308261106.r7QB6eDN065864@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, 26 Aug 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/181220 arm make xdev for arm installation fails o arm/180080 arm Unmapped buffers on ARMv7 big-RAM boards o arm/179688 arm [patch] [rpi] serial console eats some characters at m o arm/179561 arm Compilation issue for lighttpd on raspberry pi o arm/179532 arm wireless networking on ARM o arm/178495 arm buildworld fail on arm/raspberry pi o arm/177687 arm gdb gets installed but does not know the EABI version o arm/177686 arm assertion failed in ld-elf.so.1 when invoking telnet w o arm/177685 arm [kernel] [patch] Correct return type and usage of at91 o arm/177538 arm tunefs(8) and mount(8) can not access a newfs(8)'d fil o arm/176424 arm Compiler warning, TARGET_ARCH=armv6, make MALLOC_PRODU o arm/175803 arm building xdev for arm failing o arm/175605 arm please fix build binutils-2.23.1 in raspberry pi o arm/174461 arm [patch] Fix off-by-one in arm9/arm10 cache maintenance o arm/173617 arm Dreamplug exhibits eSATA file corruption using network o kern/171096 arm [arm][xscale][ixp]Allow 16bit access on PCI bus o arm/166256 arm build fail in pmap.c o arm/162159 arm [panic] USB errors leading to panic on DockStar 9.0-RC o arm/161110 arm /usr/src/sys/arm/include/signal.h is bad o arm/161044 arm devel/icu does not build on arm o arm/158950 arm arm/sheevaplug fails fsx when mmap operations are enab o arm/155894 arm [patch] Enable at91 booting from SDHC (high capacity) p arm/155214 arm [patch] MMC/SD IO slow on Atmel ARM with modern large o arm/154227 arm [geli] using GELI leads to panic on ARM o arm/153380 arm Panic / translation fault with wlan on ARM o arm/150581 arm [irq] Unknown error generates IRQ address decoding err o arm/134368 arm [new driver] [patch] nslu2_led driver for the LEDs on p arm/134338 arm [patch] Lock GPIO accesses on ixp425 28 problems total. From owner-freebsd-arm@FreeBSD.ORG Mon Aug 26 11:15:33 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 A01DFD1C for ; Mon, 26 Aug 2013 11:15:33 +0000 (UTC) (envelope-from ghw@7axu.com) Received: from mail-wg0-f52.google.com (mail-wg0-f52.google.com [74.125.82.52]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id F15BB2ABA for ; Mon, 26 Aug 2013 11:15:32 +0000 (UTC) Received: by mail-wg0-f52.google.com with SMTP id l18so2238082wgh.19 for ; Mon, 26 Aug 2013 04:15: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:from:date :message-id:subject:to:cc:content-type; bh=Se4nJl3OjR4NLgQThmijswUeZVU2zJtSpDWC1Qdiivc=; b=fdr+jzfk0rkZIZKnuWCu12h6BPsd7b3I/s9lhjr2ng5aawQs2c42ts5005mjYBwwKR SRCOcMb3n4NZsVCwcjQnrRllWKDOMMxp2VBYfH7oJ/BV/BIuI8ib20nwYelvzljfljx3 +KPFpEEiPQ3CGyh6KEniiP4wR979ub/S0Y+PUxySjEOcniffgWv2bghIWk0fcOpkwF4T SXd+eRcvxtrdUGHMJU2uxeDZF6ViAzVA7WA08j+0CRyUa1k3j6SjMq24pD8bi7+14bJH n0+YCoZYEJu8oRGSpiUJqMvjx7RAnkiPX7ZcCc3HU+LlT8rXae8s/IEi6S3CFpeKn9GZ 2pjw== X-Gm-Message-State: ALoCoQmsEY5id7oCAmGUjWNT4VfJEUcniQCpKLpt5X9jK0aZta4IJsS5BALJNoXxkE63icvZdBEn X-Received: by 10.180.8.42 with SMTP id o10mr7411340wia.0.1377515725129; Mon, 26 Aug 2013 04:15:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.175.8 with HTTP; Mon, 26 Aug 2013 04:14:44 -0700 (PDT) X-Originating-IP: [124.90.188.29] In-Reply-To: <1377262426.1111.50.camel@revolution.hippie.lan> References: <1377262426.1111.50.camel@revolution.hippie.lan> From: XiaoQI Ge Date: Mon, 26 Aug 2013 19:14:44 +0800 Message-ID: Subject: Re: My BB-Black boot failure To: Ian Lepore Content-Type: text/plain; charset=UTF-8 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, 26 Aug 2013 11:15:33 -0000 I'm using the latest source code compiled kernel (r254898) Kernel panic after start Kernel entry at 0x80200100... Kernel args: (null) 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-CURRENT #2 r254898: Tue Aug 27 00:44:45 CST 2013 root@7axu.com:/crochet-freebsd/work/obj/arm.armv6/usr/src/sys/BB-Black arm FreeBSD clang version 3.3 (tags/RELEASE_33/final 183502) 20130610 WARNING: WITNESS option enabled, expect reduced performance. WARNING: DIAGNOSTIC option enabled, expect reduced performance. subsystem 900000 mtx_pool_setup_static(0)... done. subsystem 1000000 vm_mem_init(0)... done. vm_page_init_fakepg(0)... done. subsystem 1800000 mallocinit(0)... done. malloc_init(0xc069ca90)... done. malloc_init(0xc069ca70)... done. malloc_init(&M_FILECAPS)... done. malloc_init(0xc069ccc0)... done. malloc_init(0xc069ce48)... done. malloc_init(&M_PARGS)... done. malloc_init(0xc06877f4)... done. malloc_init(0xc069d14c)... done. malloc_init(0xc069d24c)... done. malloc_init(0xc069d300)... done. malloc_init(0xc0688614)... done. malloc_init(&M_PRISON)... done. malloc_init(0xc069dd14)... done. malloc_init(0xc069e948)... done. malloc_init(0xc068b0f8)... done. malloc_init(0xc068b1f0)... done. malloc_init(&M_LINKER)... done. malloc_init(0xc068b710)... done. malloc_init(0xc069efa8)... done. malloc_init(0xc069eff0)... done. malloc_init(&M_CACHE)... done. malloc_init(&M_DEVBUF)... done. malloc_init(&M_TEMP)... done. malloc_init(&M_IP6OPT)... done. malloc_init(&M_IP6NDP)... done. malloc_init(0xc068b888)... done. malloc_init(0xc06a0648)... done. malloc_init(0xc06a0690)... done. malloc_init(0xc068b898)... done. malloc_init(&M_OFWPROP)... done. malloc_init(0xc06a0818)... done. malloc_init(&M_RANDOM_ADAPTORS)... done. malloc_init(&M_PMCHOOKS)... done. malloc_init(&M_ENTROPY)... done. malloc_init(0xc0683720)... done. malloc_init(0xc068d834)... done. malloc_init(&M_PGRP)... done. malloc_init(&M_SESSION)... done. malloc_init(0xc06a0ad0)... done. malloc_init(&M_SUBPROC)... done. malloc_init(0xc06a1180)... done. malloc_init(0xc06a12d0)... done. malloc_init(0xc06a12e0)... done. malloc_init(0xc068d99c)... done. malloc_init(0xc0683750)... done. malloc_init(&M_CAMXPT)... done. malloc_init(0xc0693520)... done. malloc_init(0xc0693530)... done. malloc_init(0xc0693510)... done. malloc_init(0xc06936bc)... done. malloc_init(0xc0693724)... done. malloc_init(&M_DEVFS)... done. malloc_init(0xc0693904)... done. malloc_init(0xc0693cd0)... done. malloc_init(0xc0693d00)... done. malloc_init(&M_MSDOSFSMNT)... done. malloc_init(0xc0693dbc)... done. malloc_init(0xc06a2094)... done. malloc_init(0xc06a2064)... done. malloc_init(0xc06a2084)... done. malloc_init(&M_NEWNFSRVCACHE)... done. malloc_init(0xc06a288c)... done. malloc_init(0xc06a28f8)... done. malloc_init(0xc06a29a0)... done. malloc_init(&M_P31B)... done. malloc_init(0xc06a3360)... done. malloc_init(0xc06a3418)... done. malloc_init(0xc06a3428)... done. malloc_init(&M_NEWNFSDCLIENT)... done. malloc_init(0xc06a3714)... done. malloc_init(0xc06a38e0)... done. malloc_init(&M_NEWNFSDSTATE)... done. malloc_init(&M_NEWNFSDLOCK)... done. malloc_init(0xc06a3bf4)... done. malloc_init(&M_NEWNFSDLOCKFILE)... done. malloc_init(0xc06a40f8)... done. malloc_init(&M_NEWNFSSTRING)... done. malloc_init(&M_NEWNFSUSERGROUP)... done. malloc_init(&M_NEWNFSDREQ)... done. malloc_init(&M_NEWNFSFH)... done. malloc_init(0xc06a4428)... done. malloc_init(0xc06a45d0)... done. malloc_init(0xc06a4600)... done. malloc_init(&M_NEWNFSCLOWNER)... done. malloc_init(&M_NEWNFSCLOPEN)... done. malloc_init(&M_NEWNFSCLDELEG)... done. malloc_init(0xc06a4840)... done. malloc_init(0xc06a48a0)... done. malloc_init(0xc06a4acc)... done. malloc_init(&M_VMEM)... done. malloc_init(0xc06a4cb4)... done. malloc_init(&M_NEWNFSCLCLIENT)... done. malloc_init(&M_NEWNFSCLLOCKOWNER)... done. malloc_init(&M_NEWNFSCLLOCK)... done. malloc_init(&M_NEWNFSV4NODE)... done. malloc_init(0xc06a4f90)... done. malloc_init(0xc06a4fa0)... done. malloc_init(&M_IOV)... done. malloc_init(0xc06a5afc)... done. malloc_init(0xc06a5eac)... done. malloc_init(0xc06a624c)... done. malloc_init(0xc06a6614)... done. malloc_init(0xc06a68b0)... done. malloc_init(&M_ACCF)... done. malloc_init(0xc06a6d90)... done. malloc_init(0xc06a6dd0)... done. malloc_init(&M_SONAME)... done. malloc_init(&M_PCB)... done. malloc_init(&M_NEWNFSDIRECTIO)... done. malloc_init(&M_ACL)... done. malloc_init(0xc06a7860)... done. malloc_init(0xc06a8034)... done. malloc_init(0xc06a86ac)... done. malloc_init(0xc06a8890)... done. malloc_init(0xc06a88d0)... done. malloc_init(&M_VNODE)... done. malloc_init(&M_NEWNFSDIROFF)... done. malloc_init(&M_NEWNFSDROLLBACK)... done. malloc_init(&M_MOUNT)... done. malloc_init(&M_NEWNFSLAYOUT)... done. malloc_init(&M_VNODE_MARKER)... done. malloc_init(&M_FADVISE)... done. malloc_init(&M_BPF)... done. malloc_init(&M_NEWNFSFLAYOUT)... done. malloc_init(0xc06a9690)... done. malloc_init(0xc06a9670)... done. malloc_init(&M_IFADDR)... done. malloc_init(&M_IFMADDR)... done. malloc_init(0xc06a97f0)... done. malloc_init(0xc06a991c)... done. malloc_init(&M_LLTABLE)... done. malloc_init(&M_NEWNFSDEVINFO)... done. malloc_init(&M_NEWNFSSOCKREQ)... done. malloc_init(&M_NEWNFSCLDS)... done. malloc_init(&M_NEWNFSLAYRECALL)... done. malloc_init(&M_NEWNFSREQ)... done. malloc_init(&M_NEWNFSMNT)... done. malloc_init(&M_RTABLE)... done. malloc_init(&M_80211_VAP)... done. malloc_init(&M_80211_CRYPTO)... done. malloc_init(0xc06aa968)... done. malloc_init(0xc06aaa78)... done. malloc_init(&M_80211_MESH_PREQ)... done. malloc_init(&M_80211_MESH_PREP)... done. malloc_init(&M_80211_MESH_PERR)... done. malloc_init(&M_80211_MESH_RT)... done. malloc_init(&M_80211_MESH_GT_RT)... done. malloc_init(&M_80211_NODE)... done. malloc_init(&M_80211_NODE_IE)... done. malloc_init(0xc06b0340)... done. malloc_init(&M_80211_RATECTL)... done. malloc_init(&M_80211_SCAN)... done. malloc_init(0xc06b0950)... done. malloc_init(0xc06b0ce0)... done. malloc_init(0xc06b0ec4)... done. malloc_init(0xc06b0e94)... done. malloc_init(0xc06b0ed4)... done. malloc_init(0xc06b0ea4)... done. malloc_init(0xc0695adc)... done. malloc_init(0xc0695bb0)... done. malloc_init(&M_TMPFSMNT)... done. malloc_init(0xc06b19ec)... done. malloc_init(0xc06b2350)... done. malloc_init(&M_TCPLOG)... done. malloc_init(0xc06b2f34)... done. malloc_init(0xc06b37b0)... done. malloc_init(0xc06b390c)... done. malloc_init(0xc06b38ec)... done. malloc_init(0xc06b391c)... done. malloc_init(0xc06b38fc)... done. malloc_init(&M_TMPFSNAME)... done. malloc_init(&M_GEOM)... done. malloc_init(&M_CAMDEV)... done. malloc_init(0xc06b4a88)... done. malloc_init(&M_CAMCCB)... done. malloc_init(&M_ISOFSMNT)... done. malloc_init(0xc06b4e9c)... done. malloc_init(0xc06b4e8c)... done. malloc_init(&M_NLM)... done. malloc_init(&M_RPC)... done. malloc_init(0xc06b5dcc)... done. malloc_init(0xc06b5ddc)... done. malloc_init(0xc06b5dfc)... done. malloc_init(0xc06b5dec)... done. malloc_init(0xc06b5f1c)... done. malloc_init(0xc06b5f2c)... done. malloc_init(0xc06b5f3c)... done. malloc_init(0xc06b5f4c)... done. malloc_init(0xc06b5f5c)... done. malloc_init(0xc06b5e3c)... done. malloc_init(0xc06b5e4c)... done. malloc_init(0xc06b5f6c)... done. malloc_init(0xc06b5f7c)... done. malloc_init(0xc06b5e5c)... done. malloc_init(0xc06b5e0c)... done. malloc_init(0xc06b5f8c)... done. malloc_init(0xc06b5f9c)... done. malloc_init(0xc06b5fac)... done. malloc_init(0xc06b5fbc)... done. malloc_init(0xc06b5e1c)... done. malloc_init(0xc06b5fcc)... done. malloc_init(0xc06b5fdc)... done. malloc_init(0xc06b5fec)... done. malloc_init(0xc06b5ffc)... done. malloc_init(0xc06b5e6c)... done. malloc_init(0xc06b600c)... done. malloc_init(0xc06b5e2c)... done. malloc_init(0xc06b601c)... done. malloc_init(0xc06b602c)... done. malloc_init(0xc06b603c)... done. malloc_init(0xc06b854c)... done. malloc_init(0xc06b86e4)... done. malloc_init(&M_UFSMNT)... done. malloc_init(0xc06b8b04)... done. malloc_init(0xc06b8de0)... done. malloc_init(&M_ISOFSNODE)... done. malloc_init(0xc0683c18)... done. malloc_init(0xc06871a4)... done. malloc_init(&M_CAMPATH)... done. malloc_init(&M_USB)... done. malloc_init(&M_USBDEV)... done. malloc_init(&M_USBHC)... done. malloc_init(&M_FICT_PAGES)... done. vm_radix_reserve_kva(0)... done. malloc_init(0xc0683684)... done. malloc_init(0xc069c640)... done. malloc_init(&M_MEMDESC)... done. malloc_init(0xc06baad8)... done. malloc_init(0xc06babac)... done. malloc_init(0xc069c700)... done. malloc_init(0xc0683700)... done. malloc_init(0xc0683710)... done. malloc_init(0xc069ca80)... done. busdma_init(0)... done. tunable_mbinit(0)... done. counter_startup(0)... done. sleepinit(0)... done. init_dynamic_kenv(0)... done. authnone_init(0)... done. authunix_init(0)... done. sysctl_register_all(0)... done. subsystem 1a80000 witness_initialize(0)... done. subsystem 1ac0000 mtx_pool_setup_dynamic(0)... done. subsystem 1b00000 nlm_client_init(0)... done. usb_quirk_init(0)... done. nlm_init(0)... done. usb_temp_init(0)... done. lf_init(0)... done. filelistinit(0)... done. mtx_sysinit(&_MergedGlobals)... done. mtx_sysinit(&_MergedGlobals)... done. sx_sysinit(0xc06885b8)... done. mtx_sysinit(&_MergedGlobals)... done. mtx_sysinit(&_MergedGlobals)... done. mtx_sysinit(0xc0688e24)... done. mtx_sysinit(&_MergedGlobals)... done. mtx_sysinit(0xc06b0c94)... done. mtx_sysinit(0xc06a32c8)... done. mtx_sysinit(&_MergedGlobals)... done. mtx_sysinit(0xc069d2a4)... done. mtx_sysinit(0xc06950d8)... done. mtx_sysinit(0xc06b0db8)... done. sx_sysinit(0xc069c41c)... done. mtx_sysinit(0xc069dc68)... done. sx_sysinit(0xc069dc5c)... done. mtx_sysinit(0xc06a36c8)... done. mtx_sysinit(&_MergedGlobals)... done. rw_sysinit(0xc06b1d64)... done. sx_sysinit(0xc06a9594)... done. rw_sysinit(0xc069e8b8)... done. mtx_sysinit(0xc0693878)... done. mtx_sysinit(0xc06a390c)... done. mtx_sysinit(&_MergedGlobals)... done. sx_sysinit(0xc069386c)... done. rw_sysinit(0xc06b59c8)... done. mtx_sysinit(0xc069cdcc)... done. rw_sysinit(&_MergedGlobals)... done. mtx_sysinit(0xc06b3810)... done. mtx_sysinit(0xc06a3cc4)... done. sx_sysinit(0xc06a65c8)... done. mtx_sysinit(0xc06a088c)... done. mtx_sysinit(0xc06b8eac)... done. rw_sysinit(&_MergedGlobals)... done. mtx_sysinit(&_MergedGlobals)... done. mtx_sysinit(&_MergedGlobals)... done. mtx_sysinit(&_MergedGlobals)... done. pmc_init_sx(0)... done. mtx_sysinit(&_MergedGlobals)... done. mtx_sysinit(0xc06ba0ac)... done. mtx_sysinit(0xc069cdc0)... done. mtx_sysinit(&_MergedGlobals)... done. mtx_sysinit(0xc069cdb4)... done. mtx_sysinit(&_MergedGlobals)... done. mtx_sysinit(&_MergedGlobals)... done. mtx_sysinit(0xc06a6f30)... done. mtx_sysinit(&_MergedGlobals)... done. mtx_sysinit(0xc06a6f24)... done. sx_sysinit(0xc068d7b8)... done. mtx_sysinit(&_MergedGlobals)... done. sx_sysinit(0xc06936d8)... done. rw_sysinit(0xc06a7fdc)... done. init_turnstile0(0)... done. osd_init(0)... done. rangelock_sys_init(0)... done. init_bounce_pages(0)... done. kobj_init_mutex(0)... done. arc4_init(0)... done. subsystem 1c00000 eventhandler_init(0)... done. subsystem 1c00001 umtxq_sysinit(0)... done. subsystem 2000000 module_init(0)... done. usb_dev_init(0)... done. dpcpu_startup(0)... done. linker_init(0)... done. link_elf_init(0)... done. linker_preload(0)... done. locks_show_all_add(0)... done. alllocks_show_add(0)... done. witness_show_add(0)... done. pcpu_show_all_add(0)... done. ifnet_show_add(0)... done. ifnets_show_all_add(0)... done. allpcpu_show_add(0)... done. pctrienode_show_add(0)... done. conifhk_show_add(0)... done. llentry_show_add(0)... done. lltable_show_add(0)... done. lltables_show_all_add(0)... done. cpusets_show_add(0)... done. pgrpdump_show_add(0)... done. msgbuf_show_add(0)... done. linker_stop_class_add(0)... done. netisr_show_add(0)... done. tty_show_add(0)... done. ttys_show_all_add(0)... done. linker_init_kernel_modules(0)... done. rman_show_add(0)... done. rmans_show_add(0)... done. socket_show_add(0)... done. sockbuf_show_add(0)... done. protosw_show_add(0)... done. sta_show_add(0)... done. statab_show_add(0)... done. vap_show_add(0)... done. com_show_add(0)... done. vaps_show_all_add(0)... done. mesh_show_all_add(0)... done. domain_show_add(0)... done. rman_show_all_add(0)... done. allrman_show_add(0)... done. watches_show_add(0)... done. intr_show_add(0)... done. sleepq_show_add(0)... done. sleepqueue_show_add(0)... done. intrcnt_show_add(0)... done. procs_show_all_add(0)... done. unpcb_show_add(0)... done. thread_show_add(0)... done. proc_show_add(0)... done. buffer_show_add(0)... done. sin_show_add(0)... done. inodedep_show_add(0)... done. inodedeps_show_add(0)... done. worklist_show_add(0)... done. workhead_show_add(0)... done. mkdirs_show_add(0)... done. ffs_show_add(0)... done. in_ifaddr_show_add(0)... done. lockedbufs_show_add(0)... done. vnodebufs_show_add(0)... done. countfreebufs_cmd_add(0)... done. file_show_add(0)... done. prison_show_add(0)... done. uma_show_add(0)... done. turnstile_show_add(0)... done. lockchain_show_add(0)... done. chains_show_all_add(0)... done. allchains_show_add(0)... done. map_show_add(0)... done. procvm_show_add(0)... done. sleepchain_show_add(0)... done. vmochk_show_add(0)... done. object_show_add(0)... done. vmopag_show_add(0)... done. inpcb_show_add(0)... done. locktree_show_add(0)... done. page_show_add(0)... done. pageq_show_add(0)... done. pginfo_show_add(0)... done. files_show_add(0)... done. cdev_show_add(0)... done. freepages_show_add(0)... done. lock_show_add(0)... done. radixnode_show_add(0)... done. lockedvnods_show_add(0)... done. vnode_show_add(0)... done. tcpcb_show_add(0)... done. mount_show_add(0)... done. geom_show_add(0)... done. malloc_show_add(0)... done. bio_show_add(0)... done. panic_cmd_add(0)... done. dpcpu_off_show_add(0)... done. pcpu_show_add(0)... done. locks_show_add(0)... done. subsystem 2100000 cpu_startup(0)... CPU: Cortex A8-r3 rev 2 (Cortex-A core) Supported features: ARM_ISA THUMB2 JAZELLE THUMBEE ARMv4 Security_Ext WB disabled EABT branch prediction enabled LoUU:2 LoC:2 LoUIS:1 Cache level 1: 32KB/64B 4-way data cache WT WB Read-Alloc 32KB/64B 4-way instruction cache Read-Alloc Cache level 2: 256KB/64B 8-way unified cache WT WB Read-Alloc Write-Alloc real memory = 536870912 (512 MB) avail memory = 515371008 (491 MB) done. lc_init(0)... done. ti_cpu_ident(0)... Texas Instruments AM3358 Processor, Revision ES1.1 done. vfp_init(0)... done. callout_callwheel_init(0)... done. subsystem 2120000 random_init(0)... done. __stack_chk_init(0)... random device not loaded; using insecure entropy done. subsystem 2140000 init_hwpmc(0)... done. subsystem 2200000 proc0_init(0)... done. shutdown_conf(0)... done. subsystem 2300000 uma_startup3(0)... done. subsystem 2380000 db_capture_sysinit(0)... done. subsystem 2400000 sched_setup(0)... done. subsystem 2480000 ktrace_init(0)... done. subsystem 2500000 create_init(0)... done. subsystem 2600000 idle_setup(0)... done. subsystem 2700000 mbuf_init(0)... done. sfstat_init(0)... done. hhook_vnet_init(0)... done. sf_buf_init(0)... done. subsystem 2800001 start_softintr(0)... done. start_softclock(0)... done. netisr_init(0)... done. subsystem 2f00000 devfs_devs_init(0)... done. subsystem 3000000 if_init(0)... done. vnet_if_init(0)... done. ether_init(0)... done. module_register_init(0xc06a9874)... done. subsystem 3100000 ieee80211_ht_init(0)... done. ttyinq_startup(0)... done. ttyoutq_startup(0)... done. module_register_init(&_MergedGlobals)... done. module_register_init(0xc06aa5d0)... done. module_register_init(0xc06a33b0)... done. ieee80211_mesh_init(0)... done. module_register_init(0xc06aa680)... done. module_register_init(0xc06b8acc)... done. module_register_init(0xc06aa700)... done. ieee80211_phy_init(0)... done. module_register_init(0xc06aa780)... done. ieee80211_auth_setup(0)... done. random_adaptors_init(0)... done. module_register_init(0xc06b0470)... done. module_register_init(0xc068f700)... done. module_register_init(0xc06b0520)... done. module_register_init(0xc0696298)... done. module_register_init(&_MergedGlobals)... done. module_register_init(&_MergedGlobals)... done. ttyconsdev_init(0)... done. module_register_init(0xc0696b3c)... done. module_register_init(0xc06a38f4)... done. module_register_init(0xc06aa9f0)... done. ieee80211_hwmp_init(0)... done. module_register_init(0xc068d5f0)... done. ctty_drvinit(0)... done. module_register_init(&_MergedGlobals)... done. module_register_init(0xc068f2cc)... done. module_register_init(0xc068f2b4)... done. module_register_init(0xc068f5d8)... done. module_register_init(0xc068c9c8)... done. module_register_init(0xc068c9b0)... done. module_register_init(0xc068c998)... done. module_register_init(0xc0693244)... done. module_register_init(0xc068c980)... done. module_register_init(0xc068c968)... done. module_register_init(&_MergedGlobals)... done. log_drvinit(0)... done. module_register_init(&_MergedGlobals)... done. module_register_init(0xc068ccf4)... done. cn_drvinit(0)... done. module_register_init(0xc069c7f0)... done. module_register_init(0xc068b314)... done. module_register_init(&_MergedGlobals)... done. module_register_init(0xc068d2a4)... done. module_register_init(0xc068b4e0)... done. module_register_init(0xc068b604)... done. module_register_init(0xc068d4c4)... random: initialized done. module_register_init(&_MergedGlobals)... done. led_drvinit(0)... done. module_register_init(0xc068b158)... done. module_register_init(&_MergedGlobals)... done. fildesc_drvinit(0)... done. module_register_init(0xc068b274)... done. module_register_init(&_MergedGlobals)... done. module_register_init(&_MergedGlobals)... done. module_register_init(0xc068b974)... done. module_register_init(&_MergedGlobals)... done. module_register_init(&_MergedGlobals)... done. module_register_init(&_MergedGlobals)... done. module_register_init(&_MergedGlobals)... done. module_register_init(&_MergedGlobals)... done. module_register_init(0xc068dd28)... done. module_register_init(0xc068dd10)... done. module_register_init(0xc068dcf8)... done. module_register_init(0xc068dce0)... done. bpf_drvinit(0)... done. module_register_init(0xc068dcc8)... done. module_register_init(0xc068dcb0)... done. module_register_init(0xc068dc98)... done. module_register_init(0xc068dc80)... done. module_register_init(0xc068dc68)... done. module_register_init(&_MergedGlobals)... done. module_register_init(&_MergedGlobals)... done. module_register_init(0xc068e3ec)... done. module_register_init(0xc068e61c)... done. module_register_init(0xc068e724)... done. module_register_init(&_MergedGlobals)... done. module_register_init(&_MergedGlobals)... done. module_register_init(&_MergedGlobals)... done. module_register_init(&_MergedGlobals)... done. module_register_init(&_MergedGlobals)... done. module_register_init(&_MergedGlobals)... done. module_register_init(&_MergedGlobals)... done. module_register_init(&_MergedGlobals)... done. module_register_init(&_MergedGlobals)... done. module_register_init(&_MergedGlobals)... done. module_register_init(&_MergedGlobals)... done. module_register_init(&_MergedGlobals)... done. module_register_init(&_MergedGlobals)... done. module_register_init(0xc06b4df4)... done. module_register_init(&_MergedGlobals)... done. module_register_init(&_MergedGlobals)... done. module_register_init(&_MergedGlobals)... done. module_register_init(&_MergedGlobals)... done. module_register_init(&_MergedGlobals)... done. module_register_init(&_MergedGlobals)... done. module_register_init(&_MergedGlobals)... done. module_register_init(0xc06bacb0)... done. module_register_init(&_MergedGlobals)... done. module_register_init(0xc06bb17c)... done. module_register_init(0xc06bb3ac)... done. module_register_init(0xc06bb550)... done. module_register_init(0xc06bb644)... done. module_register_init(0xc06bb7cc)... done. module_register_init(0xc06bb8cc)... done. module_register_init(0xc06bb990)... done. module_register_init(0xc06bb978)... done. module_register_init(&_MergedGlobals)... done. module_register_init(&_MergedGlobals)... done. module_register_init(0xc068ef88)... done. module_register_init(0xc068ef70)... done. pts_init(0)... done. module_register_init(&_MergedGlobals)... done. module_register_init(&_MergedGlobals)... done. module_register_init(0xc06bcdf0)... done. module_register_init(0xc06bcdd8)... done. module_register_init(0xc06bcf08)... done. module_register_init(0xc06837e0)... done. module_register_init(0xc0683d14)... done. module_register_init(0xc0683b70)... done. module_register_init(&_MergedGlobals)... done. module_register_init(&_MergedGlobals)... done. module_register_init(0xc06870ac)... done. module_register_init(0xc068773c)... done. module_register_init(0xc0683a74)... done. subsystem 3800000 configure_first(0)... done. taskqueue_define_thread(0)... done. taskqueue_define_fast(0)... done. module_register_init(0xc06837bc)... done. taskqueue_define_kqueue(0)... done. taskqueue_define_swi(0)... done. taskqueue_define_ffs_trim(0)... done. taskqueue_define_swi_giant(0)... done. configure(0)... simplebus0: on fdtbus0 aintc0: mem 0x48200000-0x48200fff on simplebus0 aintc0: Revision 5.0 ti_scm0: mem 0x44e10000-0x44e11fff on simplebus0 am335x_prcm0: mem 0x44e00000-0x44e012ff on simplebus0 am335x_prcm0: Clocks: System 24.0 MHz, CPU 550 MHz am335x_dmtimer0: mem 0x44e05000-0x44e05fff,0x44e31000-0x44e31fff,0x48040000-0x48040fff,0x48042000-0x48042fff,0x4804400 0-0x48044fff,0x48046000-0x48046fff,0x48048000-0x48048fff,0x4804a000-0x4804afff irq 66,67,68,69,92,93,94,95 on simplebus0 Timecounter "AM335x Timecounter" frequency 24000000 Hz quality 1000 Event timer "AM335x Eventtimer0" frequency 24000000 Hz quality 1000 gpio0: mem 0x44e07000-0x44e07fff,0x4804c000-0x4804cfff,0x481ac000-0x481acfff,0x481ae000-0x481aefff irq 96,97,98,99,32,33,62,63 on simplebus0 gpioc0: on gpio0 gpiobus0: on gpio0 uart0: mem 0x44e09000-0x44e09fff irq 72 on simplebus0 uart0: console (115384,n,8,1) ti_edma30: mem 0x49000000-0x490fffff,0x49800000-0x498fffff,0x49900000-0x499fffff,0x49a00000-0x49afffff irq 12,13,1 4 on simplebus0 ti_edma30: EDMA revision 40014c00 sdhci_ti0: mem 0x48060000-0x48060fff irq 64 on simplebus0 mmc0: on sdhci_ti0 sdhci_ti1: mem 0x481d8000-0x481d8fff irq 28 on simplebus0 mmc1: on sdhci_ti1 cpsw0: <3-port Switch Ethernet Subsystem> mem 0x4a100000-0x4a103fff irq 40,41,42,43 on simplebus0 cpsw0: CPSW SS Version 1.12 (0) cpsw0: Initial queue size TX=128 RX=384 cpsw0: Ethernet address: c8:a0:30:b2:e3:cb miibus0: on cpsw0 smscphy0: PHY 0 on miibus0 smscphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto iichb0: mem 0x44e0b000-0x44e0bfff irq 70 on simplebus0 iichb0: I2C revision 4.0 iicbus0: on iichb0 iic0: on iicbus0 am335x_pmic0: at addr 0x24 on iicbus0 am335x_pwm0: mem 0x48300000-0x483000ff,0x48300100-0x4830017f,0x48300180-0x483001ff,0x48300200-0x4830025f irq 86,58 on simp lebus0 am335x_pwm1: mem 0x48302000-0x483020ff,0x48302100-0x4830217f,0x48302180-0x483021ff,0x48302200-0x4830225f irq 87,59 on simp lebus0 am335x_pwm2: mem 0x48304000-0x483040ff,0x48304100-0x4830417f,0x48304180-0x483041ff,0x48304200-0x4830425f irq 88,60 on simp lebus0 musbotg0: mem 0x47400000-0x47400fff,0x47401000-0x474012ff,0x47401300-0x474013ff,0x47401400-0x 474017ff,0x47401800-0x47401aff,0x47401b00-0x47401bff,0x47401c00-0x47401fff irq 17,18,19 on simplebus0 musbotg0: TI AM335X USBSS v0.0.13 usbus0: Dynamic FIFO sizing detected, assuming 16Kbytes of FIFO RAM usbus0 on musbotg0 usbus1: Dynamic FIFO sizing detected, assuming 16Kbytes of FIFO RAM usbus1 on musbotg0 done. mountroot_evh_init(0)... done. vmem_start_callout(0)... done. configure_final(0)... done. subsystem 4000000 module_register_init(0xc0695684)... done. module_register_init(0xc06a31d4)... done. module_register_init(0xc06a3264)... done. vntblinit(0)... done. nameiinit(0)... done. nchinit(0)... done. vfs_hashinit(0)... done. module_register_init(0xc06970b4)... done. module_register_init(0xc0695830)... done. module_register_init(&_MergedGlobals)... done. module_register_init(0xc0693d24)... done. module_register_init(0xc06952c0)... done. module_register_init(0xc06b7e18)... done. module_register_init(&_MergedGlobals)... done. module_register_init(0xc06b5404)... done. module_register_init(0xc069499c)... done. pipeinit(0)... done. vfs_event_init(0)... done. module_register_init(0xc06b4ff4)... done. vfs_mount_init(0)... done. module_register_init(0xc06b4f18)... done. subsystem 4800000 initclocks(0)... done. inittimecounter(0)... Timecounters tick every 10.000 msec done. sched_initticks(0)... done. ntp_init(0)... done. subsystem 6400000 module_register_init(0xc06a6214)... done. shm_dict_init(0)... done. subsystem 6800000 module_register_init(0xc06a5e34)... done. subsystem 6c00000 module_register_init(0xc06a5a84)... done. subsystem 6e00000 p31binit(0)... done. sigqueue_start(0)... done. itimer_start(0)... done. p31b_set_standard(0)... done. subsystem 7000000 vnet_lltable_init(0)... done. usbpf_init(0)... done. mld_init(0)... done. igmp_init(0)... done. module_register_init(0xc06b0898)... done. knote_init(0)... done. module_register_init(0xc068f444)... done. vnet_mld_init(0)... done. module_register_init(0xc06b49b0)... done. vnet_igmp_init(0)... done. subsystem 7400000 shared_page_init(0)... done. module_register_init(0xc0695aa4)... done. elf32_insert_brand_entry(0xc06ba8d4)... done. module_register_init(0xc06977d8)... done. module_register_init(0xc06976b0)... done. elf32_insert_brand_entry(0xc06ba8b0)... done. subsystem 8000000 vnet_pfil_init(0)... done. subsystem 8400000 vnet_ether_init(0)... done. subsystem 8600000 socket_init(0)... done. domaininit(0)... done. subsystem 8800000 domain_add(0xc06a75c0)... done. domain_add(&inetdomain)... done. domain_add(0xc06aa310)... done. domain_add(&inet6domain)... done. domain_init(&inetdomain)... done. domain_init(0xc06a75c0)... done. domain_init(0xc06aa310)... done. domain_init(&inet6domain)... done. rts_init(0)... done. route_init(0)... done. vnet_route_init(0)... done. ip6_init2(0)... done. ipport_tick_init(0)... done. arp_init(0)... done. subsystem 8800001 domainfinalize(0)... done. cc_init(0)... done. if_attachdomain(0)... done. vnet_udpstat_init(0)... done. vnet_loif_init(0)... done. vnet_icmp6stat_init(0)... done. vnet_rip6stat_init(0)... done. module_register_init(&_MergedGlobals)... done. vnet_ip6stat_init(0)... done. module_register_init(&_MergedGlobals)... done. vnet_tcpstat_init(0)... done. vnet_icmpstat_init(0)... done. vnet_arpstat_init(0)... done. vnet_ipstat_init(0)... done. subsystem a000000 usb_dev_init_post(0)... done. synch_setup(0)... done. subsystem a800000 boot_run_interrupt_driven_config_hooks(0)... usbus0: 480Mbps High Speed USB v2.0 usbus1: 480Mbps High Speed USB v2.0 ugen1.1: at usbus1 uhub0: on usbus1 ugen0.1: at usbus0 uhub1: on usbus0 mmcsd0: 2GB at mmc0 48.0MHz/4bit/65535-block uhub0: 1 port with 1 removable, self powered uhub1: 1 port with 1 removable, self powered mmcsd1: 2GB at mmc1 48.0MHz/8bit/65535-block am335x_pmic0: TPS65217C ver 1.2 powered by USB done. subsystem d000000 proc0_post(0)... done. subsystem d800000 selectinit(0)... done. subsystem e000000 kick_init(0)... done. kstack_cache_init(0)... done. subsystem e400000 kproc_start(0xc06ba0c4)... done. subsystem e800000 kproc_start(0xc06ba0b8)... done. pagezero_start(0)... done. subsystem ea00000 kproc_start(0xc06a7824)... done. subsystem ec00000 kproc_start(0xc06a8b40)... done. kproc_start(0xc06a8b4c)... done. kproc_start(0xc06b59d0)... done. subsystem ee00000 nfsiod_setup(0)... done. subsystem f000000 netisr_start(0)... done. cpuset_init(0)... done. subsystem fffffff kproc_start(0xc06a305c)... done. print_caddr_t(0xc0697b54)... WARNING: WITNESS option enabled, expect reduced performance. done. print_caddr_t(0xc0697b92)... WARNING: DIAGNOSTIC option enabled, expect reduced performance. done. start_periodic_resettodr(0)... done. Trying to mount root from ufs:/dev/mmcsd0s2a [rw,noatime]... WARNING: / was not properly dismounted WARNING: /: mount pending error: blocks 88 files 0 warning: no time-of-day clock registered, system time will not be set accurately lock order reversal: 1st 0xc0a315ac pmap (pmap) @ /usr/src/sys/arm/arm/pmap-v6.c:2964 2nd 0xc0836758 pmap pv global (pmap pv global) @ /usr/src/sys/arm/arm/pmap-v6.c:695 KDB: stack backtrace: db_trace_self() at db_trace_self pc = 0xc0580ac8 lr = 0xc022dc34 (db_trace_self_wrapper+0x30) sp = 0xcd237ac0 fp = 0xcd237bd8 r10 = 0xc0a315ac db_trace_self_wrapper() at db_trace_self_wrapper+0x30 pc = 0xc022dc34 lr = 0xc03a1530 (kdb_backtrace+0x38) sp = 0xcd237be0 fp = 0xcd237be8 r4 = 0xc06d4454 r5 = 0xc060f3ad r6 = 0xc05e56a4 r7 = 0xc060f3ad kdb_backtrace() at kdb_backtrace+0x38 pc = 0xc03a1530 lr = 0xc03bb9b4 (witness_checkorder+0xddc) sp = 0xcd237bf0 fp = 0xcd237c40 r4 = 0xc05e587f witness_checkorder() at witness_checkorder+0xddc pc = 0xc03bb9b4 lr = 0xc0368ee8 (_rw_wlock_cookie+0x7c) sp = 0xcd237c48 fp = 0xcd237c70 r4 = 0x000002b7 r5 = 0xc060f3aa r6 = 0xc0836768 r7 = 0xc0836768 r8 = 0xc0836758 r9 = 0xc0a310cc r10 = 0xc0a310d8 _rw_wlock_cookie() at _rw_wlock_cookie+0x7c pc = 0xc0368ee8 lr = 0xc058ab0c (pmap_alloc_l2_bucket+0xd0) sp = 0xcd237c78 fp = 0xcd237ca0 r4 = 0xc060f3aa r5 = 0x00000000 r6 = 0xc0a20d04 r7 = 0xc0836768 r8 = 0x00008000 pmap_alloc_l2_bucket() at pmap_alloc_l2_bucket+0xd0 pc = 0xc058ab0c lr = 0xc058a8ac (pmap_copy+0x158) sp = 0xcd237ca8 fp = 0xcd237ce0 r4 = 0xc0a310bc r5 = 0x000d6000 r6 = 0xc060f3aa r7 = 0x00008000 r8 = 0x000ce000 r9 = 0xc3080020 r10 = 0x000ce000 pmap_copy() at pmap_copy+0x158 pc = 0xc058a8ac lr = 0xc0561d34 (vmspace_fork+0x784) sp = 0xcd237ce8 fp = 0xcd237d20 r4 = 0xc0a314f0 r5 = 0x00000000 r6 = 0x00008000 r7 = 0xc0a236e0 r8 = 0xc0a31000 r9 = 0xc0a235f0 r10 = 0x000ce000 vmspace_fork() at vmspace_fork+0x784 pc = 0xc0561d34 lr = 0xc033a098 (fork1+0x1a4) sp = 0xcd237d28 fp = 0xcd237d98 r4 = 0xc3059960 r5 = 0x00000000 r6 = 0xc3050320 r7 = 0x0000000c r8 = 0xc2dc8640 r9 = 0xc2dcb640 r10 = 0xcd237dac fork1() at fork1+0x1a4 pc = 0xc033a098 lr = 0xc0339ed4 (sys_fork+0x24) sp = 0xcd237da0 fp = 0xcd237db8 r4 = 0xc2dcb640 r5 = 0x00000000 r6 = 0x00000032 r7 = 0x00000000 r8 = 0xcd237e10 r9 = 0xc2dc8640 r10 = 0x00000012 sys_fork() at sys_fork+0x24 pc = 0xc0339ed4 lr = 0xc05906b0 (swi_handler+0x284) sp = 0xcd237dc0 fp = 0xcd237e58 r4 = 0xc2dcb640 r5 = 0x00000000 swi_handler() at swi_handler+0x284 pc = 0xc05906b0 lr = 0xc0582124 (swi_entry+0x2c) sp = 0xcd237e60 fp = 0xbfffe940 r4 = 0x000e01ac r5 = 0x000c6cb1 r6 = 0x00000032 r7 = 0x00000002 r8 = 0x000e0190 r9 = 0x000c6de9 swi_entry() at swi_entry+0x2c pc = 0xc0582124 lr = 0xc0582124 (swi_entry+0x2c) sp = 0xcd237e60 fp = 0xbfffe940 Unable to unwind further lock order reversal: 1st 0xc0a310bc pmap (pmap) @ /usr/src/sys/arm/arm/pmap-v6.c:2966 2nd 0xc083b940 kmem vm object (kmem vm object) @ /usr/src/sys/vm/vm_kern.c:344 KDB: stack backtrace: db_trace_self() at db_trace_self pc = 0xc0580ac8 lr = 0xc022dc34 (db_trace_self_wrapper+0x30) sp = 0xc2b0f930 fp = 0xc2b0fa48 r10 = 0xc0a310bc db_trace_self_wrapper() at db_trace_self_wrapper+0x30 pc = 0xc022dc34 lr = 0xc03a1530 (kdb_backtrace+0x38) sp = 0xc2b0fa50 fp = 0xc2b0fa58 r4 = 0xc06d4454 r5 = 0xc060a57e r6 = 0xc05e56a4 r7 = 0xc060f3ad kdb_backtrace() at kdb_backtrace+0x38 pc = 0xc03a1530 lr = 0xc03bb9b4 (witness_checkorder+0xddc) sp = 0xc2b0fa60 fp = 0xc2b0fab0 r4 = 0xc060b655 witness_checkorder() at witness_checkorder+0xddc pc = 0xc03bb9b4 lr = 0xc0368ee8 (_rw_wlock_cookie+0x7c) sp = 0xc2b0fab8 fp = 0xc2b0fae0 r4 = 0x00000158 r5 = 0xc060a57b r6 = 0xc083b950 r7 = 0xc083b940 r8 = 0xc083b940 r9 = 0x00000101 r10 = 0x00000000 _rw_wlock_cookie() at _rw_wlock_cookie+0x7c pc = 0xc0368ee8 lr = 0xc055bcc0 (kmem_back+0x68) sp = 0xc2b0fae8 fp = 0xc2b0fb28 r4 = 0xc083b940 r5 = 0x00001000 r6 = 0x00000000 r7 = 0xc083b940 r8 = 0x00000101 kmem_back() at kmem_back+0x68 pc = 0xc055bcc0 lr = 0xc055bc1c (kmem_malloc+0x6c) sp = 0xc2b0fb30 fp = 0xc2b0fb48 r4 = 0xc06d6ec0 r5 = 0x00001000 r6 = 0x00000000 r7 = 0x00000101 r8 = 0xc0554b08 r9 = 0x00000101 r10 = 0x00000000 kmem_malloc() at kmem_malloc+0x6c pc = 0xc055bc1c lr = 0xc0554b28 (page_alloc+0x20) sp = 0xc2b0fb50 fp = 0xc2b0fb50 r4 = 0xc0a5acc0 r5 = 0x00000001 r6 = 0x00000000 r7 = 0xc0a5acd0 page_alloc() at page_alloc+0x20 pc = 0xc0554b28 lr = 0xc05545bc (keg_alloc_slab+0xb4) sp = 0xc2b0fb58 fp = 0xc2b0fb80 keg_alloc_slab() at keg_alloc_slab+0xb4 pc = 0xc05545bc lr = 0xc05551f8 (keg_fetch_slab+0x148) sp = 0xc2b0fb88 fp = 0xc2b0fbc0 r4 = 0xc0a5acc0 r5 = 0xc0a55408 r6 = 0x00000001 r7 = 0xc0a55360 r8 = 0x00000000 r9 = 0xc0a553f8 r10 = 0x00000000 keg_fetch_slab() at keg_fetch_slab+0x148 pc = 0xc05551f8 lr = 0xc05555ec (zone_fetch_slab+0x64) sp = 0xc2b0fbc8 fp = 0xc2b0fbe0 r4 = 0x00000001 r5 = 0xc0a55360 r6 = 0xc0a5acc0 r7 = 0xc0a5acc0 r8 = 0x00000001 r9 = 0xc3080fa8 r10 = 0x00000002 zone_fetch_slab() at zone_fetch_slab+0x64 pc = 0xc05555ec lr = 0xc0555678 (zone_import+0x4c) sp = 0xc2b0fbe8 fp = 0xc2b0fc28 r4 = 0xc3080fac r5 = 0xc060987c r6 = 0x00000001 r7 = 0xc0a5acc0 r8 = 0x00000000 zone_import() at zone_import+0x4c pc = 0xc0555678 lr = 0xc05532e8 (uma_zalloc_arg+0x2a0) sp = 0xc2b0fc30 fp = 0xc2b0fc70 r4 = 0x00000001 r5 = 0xc060987c r6 = 0xc0a37e0c r7 = 0xc055562c r8 = 0xc0a55360 r9 = 0xc0a55418 r10 = 0xc0a37e00 uma_zalloc_arg() at uma_zalloc_arg+0x2a0 pc = 0xc05532e8 lr = 0xc058abf0 (pmap_alloc_l2_bucket+0x1b4) sp = 0xc2b0fc78 fp = 0xc2b0fca0 r4 = 0xc060f3aa r5 = 0xc0a209f8 r6 = 0xc0a209f4 r7 = 0xc0836768 r8 = 0xc060f3aa r9 = 0xc0a32aac r10 = 0xc0a32b38 pmap_alloc_l2_bucket() at pmap_alloc_l2_bucket+0x1b4 pc = 0xc058abf0 lr = 0xc058a8ac (pmap_copy+0x158) sp = 0xc2b0fca8 fp = 0xc2b0fce0 r4 = 0xc0a32a9c r5 = 0x20049000 r6 = 0xc060f3aa r7 = 0x2002e000 r8 = 0x0001b000 r9 = 0xc0a1d4b8 r10 = 0x0001b000 pmap_copy() at pmap_copy+0x158 pc = 0xc058a8ac lr = 0xc0561d34 (vmspace_fork+0x784) sp = 0xc2b0fce8 fp = 0xc2b0fd20 r4 = 0xc0a31000 r5 = 0x00000000 r6 = 0x2002e000 r7 = 0xc0a23500 r8 = 0xc0a329e0 r9 = 0xc0a24f50 r10 = 0x0001b000 vmspace_fork() at vmspace_fork+0x784 pc = 0xc0561d34 lr = 0xc033a098 (fork1+0x1a4) sp = 0xc2b0fd28 fp = 0xc2b0fd98 r4 = 0xc3059640 r5 = 0x00000000 r6 = 0xc3050000 r7 = 0x0000000c r8 = 0xc3050320 r9 = 0xc3059960 r10 = 0xc2b0fdac fork1() at fork1+0x1a4 pc = 0xc033a098 lr = 0xc0339ed4 (sys_fork+0x24) sp = 0xc2b0fda0 fp = 0xc2b0fdb8 r4 = 0xc3059960 r5 = 0x00000000 r6 = 0x00000000 r7 = 0x00000000 r8 = 0xc2b0fe10 r9 = 0xc3050320 r10 = 0x00000000 sys_fork() at sys_fork+0x24 pc = 0xc0339ed4 lr = 0xc05906b0 (swi_handler+0x284) sp = 0xc2b0fdc0 fp = 0xc2b0fe58 r4 = 0xc3059960 r5 = 0x00000000 swi_handler() at swi_handler+0x284 pc = 0xc05906b0 lr = 0xc0582124 (swi_entry+0x2c) sp = 0xc2b0fe60 fp = 0xbfffec18 r4 = 0x00030998 r5 = 0x2080d020 r6 = 0x00000000 r7 = 0x00000002 r8 = 0x00000003 r9 = 0x2080d020 swi_entry() at swi_entry+0x2c pc = 0xc0582124 lr = 0xc0582124 (swi_entry+0x2c) sp = 0xc2b0fe60 fp = 0xbfffec18 Unable to unwind further Setting hostuuid: 230ae88c-0b62-11e3-b09f-c8a030b2e3cb. Setting hostid: 0xca2b5aa2. No suitable dump device was found. Entropy harvesting: interrupts ethernet point_to_point kickstart. Starting file system checks: ** SU+J Recovering /dev/mmcsd0s2a ** Reading 4194304 byte journal from inode 4. ** Building recovery table. ** Resolving unreferenced inode list. ** Processing journal entries. ** 27 journal records in 3072 bytes for 28.12% utilization ** Freed 4 inodes (0 dirs) 0 blocks, and 1 frags. ***** FILE SYSTEM MARKED CLEAN ***** Mounting local file systems:. Writing entropy file:. Setting hostname: 7axu.com. Expensive timeout(9) function: 0xc059c5d0(0xc2e47000) 0.007522041 s cpsw0: link state changed to UP Starting Network: lo0 cpsw0. lo0: flags=8049 metric 0 mtu 16384 options=600003 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2 inet 127.0.0.1 netmask 0xff000000 nd6 options=21 cpsw0: flags=8843 metric 0 mtu 1500 options=8000b ether c8:a0:30:b2:e2:cb media: Ethernet autoselect (100baseTX ) status: active nd6 options=29 Starting devd. Starting dhclient. DHCPREQUEST on cpsw0 to 255.255.255.255 port 67 DHCPACK from 192.168.1.1 bound to 192.168.1.100 -- renewal in 3600 seconds. lock order reversal: (sleepable after non-sleepable) 1st 0xc3116d78 so_rcv (so_rcv) @ /usr/src/sys/kern/uipc_socket.c:1594 2nd 0xc3229a30 vm map (user) (vm map (user)) @ /usr/src/sys/vm/vm_map.c:3816 KDB: stack backtrace: db_trace_self() at db_trace_self pc = 0xc0580ac8 lr = 0xc022dc34 (db_trace_self_wrapper+0x30) sp = 0xc2b2d818 fp = 0xc2b2d930 r10 = 0xc3116d78 db_trace_self_wrapper() at db_trace_self_wrapper+0x30 pc = 0xc022dc34 lr = 0xc03a1530 (kdb_backtrace+0x38) sp = 0xc2b2d938 fp = 0xc2b2d940 r4 = 0xc06d4454 r5 = 0xc060a78c r6 = 0xc05e56a4 r7 = 0xc05e9937 kdb_backtrace() at kdb_backtrace+0x38 pc = 0xc03a1530 lr = 0xc03bb9b4 (witness_checkorder+0xddc) sp = 0xc2b2d948 fp = 0xc2b2d998 r4 = 0xc05e5869 witness_checkorder() at witness_checkorder+0xddc pc = 0xc03bb9b4 lr = 0xc0372b64 (_sx_slock+0x84) sp = 0xc2b2d9a0 fp = 0xc2b2d9c8 r4 = 0x00000ee8 r5 = 0xc060a789 r6 = 0xc3229a30 r7 = 0xc3229a40 r8 = 0x00000000 r9 = 0x00000000 r10 = 0xc2b2db2c _sx_slock() at _sx_slock+0x84 pc = 0xc0372b64 lr = 0xc0562d90 (vm_map_lookup+0x74) sp = 0xc2b2d9d0 fp = 0xc2b2da08 r4 = 0xc32299e0 r5 = 0xc060a789 r6 = 0x6401a000 r7 = 0x6401a000 r8 = 0x00000002 vm_map_lookup() at vm_map_lookup+0x74 pc = 0xc0562d90 lr = 0xc0557030 (vm_fault_hold+0xdc) sp = 0xc2b2da10 fp = 0xc2b2db80 r4 = 0xc32299e0 r5 = 0x00000002 r6 = 0xc2ecf960 r7 = 0x6401a000 r8 = 0xc2b2db10 r9 = 0x00000000 r10 = 0xc083b798 vm_fault_hold() at vm_fault_hold+0xdc pc = 0xc0557030 lr = 0xc0556f0c (vm_fault+0x88) sp = 0xc2b2db88 fp = 0xc2b2dba8 r4 = 0xc32299e0 r5 = 0x00000002 r6 = 0xc2ecf960 r7 = 0x6401a000 r8 = 0x00000000 r9 = 0x00000002 r10 = 0xc083b798 vm_fault() at vm_fault+0x88 pc = 0xc0556f0c lr = 0xc058fbe8 (data_abort_handler+0x2a8) sp = 0xc2b2dbb0 fp = 0xc2b2dc50 r4 = 0xc320d640 r5 = 0xc2ecf960 r6 = 0xc060fb8e r7 = 0xc320d6e8 r8 = 0xc2b2dc58 r9 = 0xc2b2deb0 r10 = 0xc32299e0 data_abort_handler() at data_abort_handler+0x2a8 pc = 0xc058fbe8 lr = 0xc0582300 (exception_exit) sp = 0xc2b2dc58 fp = 0xc2b2dd10 r4 = 0xc06aa2dc r5 = 0xc3116da4 r6 = 0xc3116d00 r7 = 0x6401a8c0 r8 = 0x00000000 r9 = 0xc3116d88 r10 = 0xc3010300 exception_exit() at exception_exit pc = 0xc0582300 lr = 0xc2ecf960 (0xc2ecf960) sp = 0xc2b2dcac fp = 0xc2b2dd10 r0 = 0x6401a8c0 r1 = 0xc3010100 r2 = 0xc05e9934 r3 = 0x000005ef r4 = 0xc06aa2dc r5 = 0xc3116da4 r6 = 0xc3116d00 r7 = 0x6401a8c0 r8 = 0x00000000 r9 = 0xc3116d88 r10 = 0xc3010300 r12 = 0x00000000 soreceive_generic() at soreceive_generic+0x4a8 pc = 0xc03e26a8 lr = 0xc03e4340 (soreceive+0x2c) sp = 0xc2b2dd18 fp = 0xc2b2dd20 r4 = 0xc2ecf960 r5 = 0x00000000 r6 = 0xc2b2dd98 r7 = 0x00000000 r8 = 0x00000006 r9 = 0xc3089c40 r10 = 0x00000800 soreceive() at soreceive+0x2c pc = 0xc03e4340 lr = 0xc03c65e4 (soo_read+0x2c) sp = 0xc2b2dd28 fp = 0xc2b2dd30 soo_read() at soo_read+0x2c pc = 0xc03c65e4 lr = 0xc03bf660 (dofileread+0xa8) sp = 0xc2b2dd38 fp = 0xc2b2dd58 dofileread() at dofileread+0xa8 pc = 0xc03bf660 lr = 0xc03bf320 (kern_readv+0x60) sp = 0xc2b2dd60 fp = 0xc2b2dd88 r4 = 0xffffffff r5 = 0x00000000 r6 = 0x00000000 r7 = 0x00000006 r8 = 0xc2b2dd98 r9 = 0xc2ecf960 r10 = 0x2081f0f0 kern_readv() at kern_readv+0x60 pc = 0xc03bf320 lr = 0xc03bf2b0 (sys_read+0x4c) sp = 0xc2b2dd90 fp = 0xc2b2ddb8 r4 = 0xc2ecf960 r5 = 0x00000000 r6 = 0xbfffe5a8 r7 = 0x00000000 r8 = 0xc2b2de10 r9 = 0xc320d640 sys_read() at sys_read+0x4c pc = 0xc03bf2b0 lr = 0xc05906b0 (swi_handler+0x284) sp = 0xc2b2ddc0 fp = 0xc2b2de58 swi_handler() at swi_handler+0x284 pc = 0xc05906b0 lr = 0xc0582124 (swi_entry+0x2c) sp = 0xc2b2de60 fp = 0xbfffedc8 r4 = 0x00037908 r5 = 0x0002d268 r6 = 0xbfffe5a8 r7 = 0x00000003 r8 = 0x00000000 r9 = 0x521b2dfb swi_entry() at swi_entry+0x2c pc = 0xc0582124 lr = 0xc0582124 (swi_entry+0x2c) sp = 0xc2b2de60 fp = 0xbfffedc8 Unable to unwind further vm_fault(0xc32299e0, 6401a000, 2, 0) -> 5 Fatal kernel mode data abort: 'Translation Fault (S)' trapframe: 0xc2b2dc58 FSR=00000805, FAR=6401a8c4, spsr=20000013 r0 =6401a8c0, r1 =c3010100, r2 =c05e9934, r3 =000005ef r4 =c06aa2dc, r5 =c3116da4, r6 =c3116d00, r7 =6401a8c0 r8 =00000000, r9 =c3116d88, r10=c3010300, r11=c2b2dd10 r12=00000000, ssp=c2b2dca8, slr=c2ecf960, pc =c03e26a8 [ thread pid 540 tid 100064 ] Stopped at soreceive_generic+0x4a8: str r1, [r0, #0x004] db> bt Tracing pid 540 tid 100064 td 0xc2ecf960 db_trace_self() at db_trace_self pc = 0xc0580ac8 lr = 0xc022bc90 (db_stack_trace+0xf4) sp = 0xc2b2d960 fp = 0xc2b2d978 r10 = 0xc0688a70 db_stack_trace() at db_stack_trace+0xf4 pc = 0xc022bc90 lr = 0xc022b5fc (db_command+0x264) sp = 0xc2b2d980 fp = 0xc2b2da20 r4 = 0x00000000 r5 = 0x00000000 r6 = 0xc05e45af db_command() at db_command+0x264 pc = 0xc022b5fc lr = 0xc022b36c (db_command_loop+0x60) sp = 0xc2b2da28 fp = 0xc2b2da38 r4 = 0xc05c2be0 r5 = 0xc05dddbe r6 = 0xc08377e0 r7 = 0xc2b2dc58 r8 = 0xc2b2dc58 r9 = 0xc06d4454 r10 = 0xc0688ce0 db_command_loop() at db_command_loop+0x60 pc = 0xc022b36c lr = 0xc022dd6c (db_trap+0xdc) sp = 0xc2b2da40 fp = 0xc2b2db60 r4 = 0x00000000 r5 = 0xc2b2da48 r6 = 0xc06d4480 db_trap() at db_trap+0xdc pc = 0xc022dd6c lr = 0xc03a19e0 (kdb_trap+0xd4) sp = 0xc2b2db68 fp = 0xc2b2db88 r4 = 0x00000000 r5 = 0x00000805 r6 = 0xc06d4480 r7 = 0xc2b2dc58 kdb_trap() at kdb_trap+0xd4 pc = 0xc03a19e0 lr = 0xc058ff7c (dab_fatal+0x174) sp = 0xc2b2db90 fp = 0xc2b2dba8 r4 = 0xc2b2dc58 r5 = 0x600000d3 r6 = 0x6401a8c4 r7 = 0x00000805 r8 = 0xc2b2dc58 r9 = 0x00000005 r10 = 0xc32299e0 dab_fatal() at dab_fatal+0x174 pc = 0xc058ff7c lr = 0xc058fde0 ($d) sp = 0xc2b2dbb0 fp = 0xc2b2dc50 r4 = 0xc320d640 r5 = 0xc2ecf960 r6 = 0xc320d6e8 r7 = 0xc060fb8e $d() at $d pc = 0xc058fde0 lr = 0xc0582300 (exception_exit) sp = 0xc2b2dc58 fp = 0xc2b2dd10 r4 = 0xc06aa2dc r5 = 0xc3116da4 r6 = 0xc3116d00 r7 = 0x6401a8c0 r8 = 0x00000000 r9 = 0xc3116d88 r10 = 0xc3010300 exception_exit() at exception_exit pc = 0xc0582300 lr = 0xc2ecf960 (0xc2ecf960) sp = 0xc2b2dcac fp = 0xc2b2dd10 r0 = 0x6401a8c0 r1 = 0xc3010100 r2 = 0xc05e9934 r3 = 0x000005ef r4 = 0xc06aa2dc r5 = 0xc3116da4 r6 = 0xc3116d00 r7 = 0x6401a8c0 r8 = 0x00000000 r9 = 0xc3116d88 r10 = 0xc3010300 r12 = 0x00000000 soreceive_generic() at soreceive_generic+0x4a8 pc = 0xc03e26a8 lr = 0xc03e4340 (soreceive+0x2c) sp = 0xc2b2dd18 fp = 0xc2b2dd20 r4 = 0xc2ecf960 r5 = 0x00000000 r6 = 0xc2b2dd98 r7 = 0x00000000 r8 = 0x00000006 r9 = 0xc3089c40 r10 = 0x00000800 soreceive() at soreceive+0x2c pc = 0xc03e4340 lr = 0xc03c65e4 (soo_read+0x2c) sp = 0xc2b2dd28 fp = 0xc2b2dd30 soo_read() at soo_read+0x2c pc = 0xc03c65e4 lr = 0xc03bf660 (dofileread+0xa8) sp = 0xc2b2dd38 fp = 0xc2b2dd58 dofileread() at dofileread+0xa8 pc = 0xc03bf660 lr = 0xc03bf320 (kern_readv+0x60) sp = 0xc2b2dd60 fp = 0xc2b2dd88 r4 = 0xffffffff r5 = 0x00000000 r6 = 0x00000000 r7 = 0x00000006 r8 = 0xc2b2dd98 r9 = 0xc2ecf960 r10 = 0x2081f0f0 kern_readv() at kern_readv+0x60 pc = 0xc03bf320 lr = 0xc03bf2b0 (sys_read+0x4c) sp = 0xc2b2dd90 fp = 0xc2b2ddb8 r4 = 0xc2ecf960 r5 = 0x00000000 r6 = 0xbfffe5a8 r7 = 0x00000000 r8 = 0xc2b2de10 r9 = 0xc320d640 sys_read() at sys_read+0x4c pc = 0xc03bf2b0 lr = 0xc05906b0 (swi_handler+0x284) sp = 0xc2b2ddc0 fp = 0xc2b2de58 swi_handler() at swi_handler+0x284 pc = 0xc05906b0 lr = 0xc0582124 (swi_entry+0x2c) sp = 0xc2b2de60 fp = 0xbfffedc8 r4 = 0x00037908 r5 = 0x0002d268 r6 = 0xbfffe5a8 r7 = 0x00000003 r8 = 0x00000000 r9 = 0x521b2dfb swi_entry() at swi_entry+0x2c pc = 0xc0582124 lr = 0xc0582124 (swi_entry+0x2c) sp = 0xc2b2de60 fp = 0xbfffedc8 Unable to unwind further db> From owner-freebsd-arm@FreeBSD.ORG Mon Aug 26 11:32: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 90922CD; Mon, 26 Aug 2013 11:32:15 +0000 (UTC) (envelope-from peter@rulingia.com) Received: from vps.rulingia.com (host-122-100-2-194.octopus.com.au [122.100.2.194]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id B6F032BA2; Mon, 26 Aug 2013 11:32:13 +0000 (UTC) Received: from server.rulingia.com (c220-239-237-213.belrs5.nsw.optusnet.com.au [220.239.237.213]) by vps.rulingia.com (8.14.5/8.14.5) with ESMTP id r7QBHSCq038408 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 26 Aug 2013 21:17:28 +1000 (EST) (envelope-from peter@rulingia.com) X-Bogosity: Ham, spamicity=0.000000 Received: from server.rulingia.com (localhost.rulingia.com [127.0.0.1]) by server.rulingia.com (8.14.7/8.14.7) with ESMTP id r7QBHNUQ045144 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 26 Aug 2013 21:17:23 +1000 (EST) (envelope-from peter@server.rulingia.com) Received: (from peter@localhost) by server.rulingia.com (8.14.7/8.14.7/Submit) id r7QBHMR3045143; Mon, 26 Aug 2013 21:17:22 +1000 (EST) (envelope-from peter) Date: Mon, 26 Aug 2013 21:17:22 +1000 From: Peter Jeremy To: Adrian Chadd Subject: Re: Pretty good RPi version? Message-ID: <20130826111722.GA42792@server.rulingia.com> References: <5218FBE2.2000907@m5p.com> <20130825.195532.59669686.shigeru@os-hackers.jp> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="SUOF0GtieIMvvwua" Content-Disposition: inline In-Reply-To: X-PGP-Key: http://www.rulingia.com/keys/peter.pgp User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Aug 2013 11:32:15 -0000 --SUOF0GtieIMvvwua Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2013-Aug-25 05:07:37 -0700, Adrian Chadd wrote: >All - if it's unstable, please complain loudly on -arm and -current and >file PRs. If you have the time, please help figure out which commit(s) >broke things. I have yet to find a 10.x that I can compile natively on my RPi. When it takes 24-36 hours to fail, tracking down issues is painful. Recent failures: r252338: >>> stage 4.2: building libraries =2E.. =3D=3D=3D> cddl/lib/libavl (all) cc -O -pipe -I/a/src/cddl/lib/libavl/../../../sys/cddl/compat/opensolari= s -I/a/src/cddl/lib/libavl/../../../sys/cddl/contrib/opensolaris/uts/common= -DNEED_SOLARIS_BOOLEAN -std=3Dgnu89 -Qunused-arguments -Wno-pointer-sign -= Wno-empty-body -Wno-string-plus-int -Wno-tautological-compare -Wno-unused-v= alue -Wno-parentheses-equality -Wno-unused-function -Wno-conversion -Wno-sw= itch -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses -Wno-unk= nown-pragmas -c /a/src/cddl/lib/libavl/../../../sys/cddl/contrib/opensolari= s/common/avl/avl.c -o avl.o building static avl library ranlib libavl.a cc -fpic -DPIC -O -pipe -I/a/src/cddl/lib/libavl/../../../sys/cddl/compa= t/opensolaris -I/a/src/cddl/lib/libavl/../../../sys/cddl/contrib/opensolari= s/uts/common -DNEED_SOLARIS_BOOLEAN -std=3Dgnu89 -Qunused-arguments -Wno-po= inter-sign -Wno-empty-body -Wno-string-plus-int -Wno-tautological-compare -= Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-conver= sion -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parenthe= ses -Wno-unknown-pragmas -c /a/src/cddl/lib/libavl/../../../sys/cddl/contri= b/opensolaris/common/avl/avl.c -o avl.So building shared library libavl.so.2 /usr/obj/a/src/tmp/usr/bin/ld: cannot find -lgcc_s cc: error: linker command failed with exit code 1 (use -v to see invocation) *** Error code 1 Stop. make: stopped in /a/src/cddl/lib/libavl r253885: >>> stage 4.2: building libraries =2E.. =3D=3D=3D> lib/libc (obj,depend,all,install) =2E.. cc -O -pipe -I/a/src/lib/libc/include -I/a/src/lib/libc/../../include -I= /a/src/lib/libc/arm -DNLS -D__DBINTERFACE_PRIVATE -I/a/src/lib/libc/../..= /contrib/gdtoa -I/a/src/lib/libc/../../contrib/libc-vis -DINET6 -I/usr/obj/= a/src/lib/libc -I/a/src/lib/libc/resolv -D_ACL_PRIVATE -DPOSIX_MISTAKE -I/a= /src/lib/libc/../../contrib/jemalloc/include -I/a/src/lib/libc/../../contri= b/tzcode/stdtime -I/a/src/lib/libc/stdtime -I/a/src/lib/libc/locale -DBROK= EN_DES -DPORTMAP -DDES_BUILTIN -I/a/src/lib/libc/rpc -I/a/src/lib/libc/arm/= softfloat -I/a/src/lib/libc/softfloat -DSOFTFLOAT_FOR_GCC -DNS_CACHING -DSY= MBOL_VERSIONING -std=3Dgnu99 -Qunused-arguments -Wsystem-headers -Werror -W= all -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body -W= no-string-plus-int -Wno-tautological-compare -Wno-unused-value -Wno-parenth= eses-equality -Wno-unused-function -Wno-conversion -Wno-switch -Wno-switch-= enum -Wno-knr-promoted-parameter -c /a/src/lib/libc/gmon/gmon.c -o gmon.o Assertion failed: (Alignment && (Alignment & (Alignment - 1)) =3D=3D 0 && "= Alignment is not a power of two!"), function AlignPtr, file /a/src/lib/clan= g/libllvmsupport/../../../contrib/llvm/lib/Support/Allocator.cpp, line 38. Stack dump: 0. Program arguments: /a/obj/a/src/tmp/usr/bin/cc -cc1 -triple armv6--= freebsd10.0-gnueabi -S -disable-free -main-file-name gmon.c -mrelocation-mo= del static -mdisable-fp-elim -mconstructor-aliases -target-abi aapcs-linux = -target-cpu arm1136jf-s -msoft-float -mfloat-abi soft -target-feature +soft= -float -target-feature +soft-float-abi -target-feature -neon -coverage-file= /tmp/gmon-szmHXi.s -resource-dir /a/obj/a/src/tmp/usr/bin/../lib/clang/3.3= -D NLS -D __DBINTERFACE_PRIVATE -D INET6 -D _ACL_PRIVATE -D POSIX_MISTAKE = -D BROKEN_DES -D PORTMAP -D DES_BUILTIN -D SOFTFLOAT_FOR_GCC -D NS_CACHING = -D SYMBOL_VERSIONING -I /a/src/lib/libc/include -I /a/src/lib/libc/../../in= clude -I /a/src/lib/libc/arm -I /a/src/lib/libc/../../contrib/gdtoa -I /a/s= rc/lib/libc/../../contrib/libc-vis -I /usr/obj/a/src/lib/libc -I /a/src/lib= /libc/resolv -I /a/src/lib/libc/../../contrib/jemalloc/include -I /a/src/li= b/libc/../../contrib/tzcode/stdtime -I /a/src/lib/libc/stdtime -I /a/src/li= b/libc/locale -I /a/src/lib/libc/rpc -I /a/src/lib/libc/arm/softfloat -I /a= /src/lib/libc/softfloat -isysroot /usr/obj/a/src/tmp -O2 -Wsystem-headers -= Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -Wno-empt= y-body -Wno-string-plus-int -Wno-tautological-compare -Wno-unused-value -Wn= o-parentheses-equality -Wno-unused-function -Wno-conversion -Wno-switch -Wn= o-switch-enum -Wno-knr-promoted-parameter -std=3Dgnu99 -fno-dwarf-directory= -asm -fdebug-compilation-dir /usr/obj/a/src/lib/libc -ferror-limit 19 -fmes= sage-length 80 -mstackrealign -fno-signed-char -fobjc-runtime=3Dgnustep -fo= bjc-default-synthesize-properties -fdiagnostics-show-option -fcolor-diagnos= tics -backend-option -vectorize-loops -o /tmp/gmon-szmHXi.s -x c /a/src/lib= /libc/gmon/gmon.c=20 1. /a/src/lib/libc/gmon/gmon.c:121:1: current parser token 'void' 2. /a/src/lib/libc/gmon/gmon.c:73:1: LLVM IR generation of declaration= 'monstartup' 3. /a/src/lib/libc/gmon/gmon.c:73:1: Generating code for declaration '= monstartup' cc: error: unable to execute command: Abort trap (core dumped) cc: error: clang frontend command failed due to signal (use -v to see invoc= ation) FreeBSD clang version 3.3 (tags/RELEASE_33/final 183502) 20130610 Target: armv6--freebsd10.0-gnueabi Thread model: posix cc: note: diagnostic msg: PLEASE submit a bug report to http://llvm.org/bug= s/ and include the crash backtrace, preprocessed source, and associated run= script. cc: note: diagnostic msg: Error generating preprocessed source(s). *** Error code 254 Stop. make: stopped in /a/src/lib/libc r254815: This failed but unfortunately I lost the build log. --=20 Peter Jeremy --SUOF0GtieIMvvwua Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (FreeBSD) iEYEARECAAYFAlIbOUIACgkQ/opHv/APuIeDdQCeJCBiPxp6hc14X0tWVBQild/E SIMAn1EHAoCfiP1oy1/XZKmisN4bhvI0 =5FEj -----END PGP SIGNATURE----- --SUOF0GtieIMvvwua-- From owner-freebsd-arm@FreeBSD.ORG Mon Aug 26 12:37:37 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 EF225E71 for ; Mon, 26 Aug 2013 12:37:36 +0000 (UTC) (envelope-from ray@ddteam.net) Received: from mail-wg0-f49.google.com (mail-wg0-f49.google.com [74.125.82.49]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 811D52028 for ; Mon, 26 Aug 2013 12:37:36 +0000 (UTC) Received: by mail-wg0-f49.google.com with SMTP id a12so899382wgh.16 for ; Mon, 26 Aug 2013 05:37:28 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-type:content-transfer-encoding; bh=THUuHqtJ/Ort8iYCK+ETQp1Iwii71IuubATBk7iIVTM=; b=GTcQlMuHsQ+K4NdsBmY+hUVToZMvvzHll15EzpbcfhtYtY3DAmj1+7SIfxUzyyRUdG S0VC+skb4XV33KIHtuiQ777AectQ/iqJiUAIo8t5oNouJ1fJAEKvbdtT85cy1bJe+mUh s3Q9qqwKOCQoY7G+iFp0MTDalJ7iZZVzYK2i+QRxaFomboK+zoOCBivwz8ERMvhSZ86L rOsDCquFzBJUptdz0c1W9ZO1Bep8uA+Lew+LvIwfgfRbt2huSt6FKX0STX0cDENS90Jw bMYcpQ9MTGzQzm+99eae2TsafuX91TOfuyuTlQfuayMxop11Qbx8IfDDG9HJ5QCj5xol vJGQ== X-Gm-Message-State: ALoCoQkzUvtMlJcGQl98JY08TufetOzk0FAzMIhU7I3sJjSk2F9GvYsbOxpsRCIuFS+ctUrHLRx5 X-Received: by 10.194.94.37 with SMTP id cz5mr129542wjb.55.1377520648384; Mon, 26 Aug 2013 05:37:28 -0700 (PDT) Received: from raynote.ddteam.net (global-1-18.nat.csx.cam.ac.uk. [131.111.184.18]) by mx.google.com with ESMTPSA id iz19sm17978426wic.9.1969.12.31.16.00.00 (version=TLSv1.2 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 26 Aug 2013 05:37:27 -0700 (PDT) Date: Mon, 26 Aug 2013 15:37:24 +0300 From: Aleksandr Rybalko To: Ganbold Tsagaankhuu Subject: Re: Pretty good RPi version? Message-Id: <20130826153724.a08761b387dd513fdc79c63e@ddteam.net> In-Reply-To: References: <5218FBE2.2000907@m5p.com> <70652C61-98B0-40E2-BB98-B8B414E30219@alvermark.net> X-Mailer: Sylpheed 3.3.0 (GTK+ 2.24.19; amd64-portbld-freebsd10.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII 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: Mon, 26 Aug 2013 12:37:37 -0000 On Mon, 26 Aug 2013 18:17:57 +0800 Ganbold Tsagaankhuu wrote: > On Mon, Aug 26, 2013 at 4:34 PM, Jakob Alvermark wrote: > > > On 25 aug 2013, at 17:27, Tim Kientzle wrote: > > > > > > > > On Aug 25, 2013, at 12:55 AM, Jia-Shiun Li wrote: > > > > > >> On Sun, Aug 25, 2013 at 2:30 AM, George Mitchell < > > george+freebsd@m5p.com> wrote: > > >>> What's a pretty good recent Raspberry Pi svn checkout version? 254544 > > >>> doesn't seem to be it -- it crashes as soon as I try to make install in > > >>> /usr/ports/ports-mgmt/pkg. Although I'm tempted to grab one of the > > >>> prebuilt images at http://www.db.net/downloads/, I'll have to be doing > > >>> some recompiling for debug purposes. I see that latest couple of > > >>> versions there are 252209 and 250580. Are those pretty good? (By > > >>> "pretty good", I mean capable of running a light load in a fairly > > >>> stable way over a period of days.) Thanks for your help! -- George > > >> > > >> I got the same question. I was trying to update RPi this week, but > > >> several attempts has failed. RPi would hang at high load like > > >> "portsnap fetch extract" or "cd /usr/ports/graphics/graphviz && make > > >> install clean". By "hang" I mean ssh session and console had no > > >> response. But it still replies to ICMP and TCP connection handshake > > >> requests. Looks like something got stuck in the kernel. > > > > > > Do you have a serial console? > > > > > > If so, is it still responsive there? > > > > > > I've been seeing a similar problem on BB. In those > > > cases, typing a key on the serial console unblocks it. > > > > Hi, I see something similar on my Allwinner A13 (Olimex board) > > > > Running 'portsnap fetch' hangs after a while. > > > > Serial console is dead as well! > > > > A13 support is not in the tree, but it is very similar to the A10 > > (Cubieboard). I have some local patches, which I intend to send to someone > > for review (Tim? Ganbold?) > > > > In my case I asked gonzo@ and ray@ to review A10/A20 related changes. > > Ganbold > Yeah, Jakob, you can send patches to arm@ list itself. But if you want to do it less public for now, send it to me (ray@). But I can't promise if it will be fast. :) > > > > I just need to get around to clean them up a bit first. > > > > Jakob > > _______________________________________________ > > 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" -- Aleksandr Rybalko From owner-freebsd-arm@FreeBSD.ORG Mon Aug 26 14:09: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 353A53D4 for ; Mon, 26 Aug 2013 14:09:46 +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 ECD8F26BE for ; Mon, 26 Aug 2013 14:09:45 +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 1VDxUB-00080W-8a; Mon, 26 Aug 2013 14:09:39 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id r7QE9YEX051800; Mon, 26 Aug 2013 08:09:35 -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+C9SWKYCC243Y8lIq58TWp Subject: Re: My BB-Black boot failure From: Ian Lepore To: XiaoQI Ge In-Reply-To: References: <1377262426.1111.50.camel@revolution.hippie.lan> Content-Type: text/plain; charset="us-ascii" Date: Mon, 26 Aug 2013 08:09:34 -0600 Message-ID: <1377526174.1111.138.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Aug 2013 14:09:46 -0000 On Mon, 2013-08-26 at 19:14 +0800, XiaoQI Ge wrote: > I'm using the latest source code compiled kernel (r254898) > Kernel panic after start > > Kernel entry at 0x80200100... > Kernel args: (null) > 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-CURRENT #2 r254898: Tue Aug 27 00:44:45 CST 2013 > root@7axu.com:/crochet-freebsd/work/obj/arm.armv6/usr/src/sys/BB-Black arm > FreeBSD clang version 3.3 (tags/RELEASE_33/final 183502) 20130610 > WARNING: WITNESS option enabled, expect reduced performance. > WARNING: DIAGNOSTIC option enabled, expect reduced performance. > [snip] > [ thread pid 540 tid 100064 ] > Stopped at soreceive_generic+0x4a8: str r1, [r0, #0x004] > db> bt > Tracing pid 540 tid 100064 td 0xc2ecf960 > db_trace_self() at db_trace_self > pc = 0xc0580ac8 lr = 0xc022bc90 (db_stack_trace+0xf4) > sp = 0xc2b2d960 fp = 0xc2b2d978 > r10 = 0xc0688a70 > db_stack_trace() at db_stack_trace+0xf4 > pc = 0xc022bc90 lr = 0xc022b5fc (db_command+0x264) > sp = 0xc2b2d980 fp = 0xc2b2da20 > r4 = 0x00000000 r5 = 0x00000000 > r6 = 0xc05e45af > db_command() at db_command+0x264 > pc = 0xc022b5fc lr = 0xc022b36c (db_command_loop+0x60) > sp = 0xc2b2da28 fp = 0xc2b2da38 > r4 = 0xc05c2be0 r5 = 0xc05dddbe > r6 = 0xc08377e0 r7 = 0xc2b2dc58 > r8 = 0xc2b2dc58 r9 = 0xc06d4454 > r10 = 0xc0688ce0 > db_command_loop() at db_command_loop+0x60 > pc = 0xc022b36c lr = 0xc022dd6c (db_trap+0xdc) > sp = 0xc2b2da40 fp = 0xc2b2db60 > r4 = 0x00000000 r5 = 0xc2b2da48 > r6 = 0xc06d4480 > db_trap() at db_trap+0xdc > pc = 0xc022dd6c lr = 0xc03a19e0 (kdb_trap+0xd4) > sp = 0xc2b2db68 fp = 0xc2b2db88 > r4 = 0x00000000 r5 = 0x00000805 > r6 = 0xc06d4480 r7 = 0xc2b2dc58 > kdb_trap() at kdb_trap+0xd4 > pc = 0xc03a19e0 lr = 0xc058ff7c (dab_fatal+0x174) > sp = 0xc2b2db90 fp = 0xc2b2dba8 > r4 = 0xc2b2dc58 r5 = 0x600000d3 > r6 = 0x6401a8c4 r7 = 0x00000805 > r8 = 0xc2b2dc58 r9 = 0x00000005 > r10 = 0xc32299e0 > dab_fatal() at dab_fatal+0x174 > pc = 0xc058ff7c lr = 0xc058fde0 ($d) > sp = 0xc2b2dbb0 fp = 0xc2b2dc50 > r4 = 0xc320d640 r5 = 0xc2ecf960 > r6 = 0xc320d6e8 r7 = 0xc060fb8e > $d() at $d > pc = 0xc058fde0 lr = 0xc0582300 (exception_exit) > sp = 0xc2b2dc58 fp = 0xc2b2dd10 > r4 = 0xc06aa2dc r5 = 0xc3116da4 > r6 = 0xc3116d00 r7 = 0x6401a8c0 > r8 = 0x00000000 r9 = 0xc3116d88 > r10 = 0xc3010300 > exception_exit() at exception_exit > pc = 0xc0582300 lr = 0xc2ecf960 (0xc2ecf960) > sp = 0xc2b2dcac fp = 0xc2b2dd10 > r0 = 0x6401a8c0 r1 = 0xc3010100 > r2 = 0xc05e9934 r3 = 0x000005ef > r4 = 0xc06aa2dc r5 = 0xc3116da4 > r6 = 0xc3116d00 r7 = 0x6401a8c0 > r8 = 0x00000000 r9 = 0xc3116d88 > r10 = 0xc3010300 r12 = 0x00000000 > soreceive_generic() at soreceive_generic+0x4a8 > pc = 0xc03e26a8 lr = 0xc03e4340 (soreceive+0x2c) > sp = 0xc2b2dd18 fp = 0xc2b2dd20 > r4 = 0xc2ecf960 r5 = 0x00000000 > r6 = 0xc2b2dd98 r7 = 0x00000000 > r8 = 0x00000006 r9 = 0xc3089c40 > r10 = 0x00000800 > soreceive() at soreceive+0x2c > pc = 0xc03e4340 lr = 0xc03c65e4 (soo_read+0x2c) > sp = 0xc2b2dd28 fp = 0xc2b2dd30 > soo_read() at soo_read+0x2c > pc = 0xc03c65e4 lr = 0xc03bf660 (dofileread+0xa8) > sp = 0xc2b2dd38 fp = 0xc2b2dd58 > dofileread() at dofileread+0xa8 > pc = 0xc03bf660 lr = 0xc03bf320 (kern_readv+0x60) > sp = 0xc2b2dd60 fp = 0xc2b2dd88 > r4 = 0xffffffff r5 = 0x00000000 > r6 = 0x00000000 r7 = 0x00000006 > r8 = 0xc2b2dd98 r9 = 0xc2ecf960 > r10 = 0x2081f0f0 > kern_readv() at kern_readv+0x60 > pc = 0xc03bf320 lr = 0xc03bf2b0 (sys_read+0x4c) > sp = 0xc2b2dd90 fp = 0xc2b2ddb8 > r4 = 0xc2ecf960 r5 = 0x00000000 > r6 = 0xbfffe5a8 r7 = 0x00000000 > r8 = 0xc2b2de10 r9 = 0xc320d640 > sys_read() at sys_read+0x4c > pc = 0xc03bf2b0 lr = 0xc05906b0 (swi_handler+0x284) > sp = 0xc2b2ddc0 fp = 0xc2b2de58 > swi_handler() at swi_handler+0x284 > pc = 0xc05906b0 lr = 0xc0582124 (swi_entry+0x2c) > sp = 0xc2b2de60 fp = 0xbfffedc8 > r4 = 0x00037908 r5 = 0x0002d268 > r6 = 0xbfffe5a8 r7 = 0x00000003 > r8 = 0x00000000 r9 = 0x521b2dfb > swi_entry() at swi_entry+0x2c > pc = 0xc0582124 lr = 0xc0582124 (swi_entry+0x2c) > sp = 0xc2b2de60 fp = 0xbfffedc8 > Unable to unwind further > db> Several people are experiencing this address fault or similar ones, sometimes in in_cksum() instead of so_receivegeneric(). It looks like the latest revision that I can build and boot the BB without any trouble is r254777. The revision that actually breaks things appears to be r254807 (kudos to Zbyszek Bodek for tracking it down to this rev), so you can boot using r254806 but to get that rev to build you have to also apply the changes from r254814. There was a large flurry of checkins over the past few days to get things in before the cutoff for the 10.0 release. I have a feeling it will be a few days before the dust settles and we get some fixes. -- Ian From owner-freebsd-arm@FreeBSD.ORG Mon Aug 26 18:54: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 D6A0BFD5 for ; Mon, 26 Aug 2013 18:54:59 +0000 (UTC) (envelope-from ThomasSkibo@sbcglobal.net) Received: from nm3-vm5.access.bullet.mail.bf1.yahoo.com (nm3-vm5.access.bullet.mail.bf1.yahoo.com [216.109.114.100]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 7A5E727FA for ; Mon, 26 Aug 2013 18:54:59 +0000 (UTC) Received: from [66.196.81.157] by nm3.access.bullet.mail.bf1.yahoo.com with NNFMP; 26 Aug 2013 18:51:36 -0000 Received: from [98.139.221.55] by tm3.access.bullet.mail.bf1.yahoo.com with NNFMP; 26 Aug 2013 18:51:36 -0000 Received: from [127.0.0.1] by smtp108.sbc.mail.bf1.yahoo.com with NNFMP; 26 Aug 2013 18:51:36 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sbcglobal.net; s=s1024; t=1377543096; bh=IqLRms5m/yTM8pwP/52Ohy359IWWVObQOcfuIGS0Fg0=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=SynR7O8FcYsyWN2PnNNFf8IsrsOUvvXXElgTJsIvJ+Kj2AlIdh69UDM7Y7TTmFqmrEnqRtaGQL7uDM+UhmpITyAgYLwbLXTGo1PWqShLlZb8/zWDKiJY9m/aSDTO12WLBBwstdInS+eM4FQbs2dx5XaTCMeV0+n86QzihM1VoLU= X-Yahoo-Newman-Id: 816214.61709.bm@smtp108.sbc.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: LTLWdlQVM1l6IxxxFUsuQj2JgIyuEV.dlwBUcyGQ_O.6AbL RBfc28X7Z9vSJirCUvHXfgjtpKhIPHocqm1b.3q9JUdcji2NzDOYjFCzGITq giFD9i_lrOQj5FS23pxZDf9M7TsTfVcKm1iODwP_DPu.wjjUAZXvaQ26kj3a C934H7j2orRYP4qrcMUYAJqFxBXSJaSWOnnyrm.Tfj1PBwqyc3Ii0zemOIV4 pvmzzbW3E7B6MxEWQ5rTmaC1.ALIAPrWcvaUKSY0pmu7lqHHiLtPg1zbS5P2 XoiJUdq8DbwxbksVvZEPoD6cnDq6aMpIDy7.L3QD.k7gVIWrnI8llWMjxLH0 KeQT1qLllLBSssHjpxLSJHMH.Wwf6dZsUOMRODUGpM2F_7Z2.UTMqtq0OKbS yhWRkIhpW8p0dxZMV8EZJgcP69ybTiM7bWDDYCJRESgD0Lee2ACLApckDmTr 9V5DuJB.dQjQz98OMAU_RDI_ZDUNqp9sratuSjGY73t0zEi.GIItnu41wOJS O52VnlJ.Q8aveyxsHBEOOB9CNDqni.MX6qBGuHiHYPc7b5pXV5ij9lQ-- X-Yahoo-SMTP: tUxoRneswBA21azLM.3ybMESf0mC2bFhTbmt0VU5ervH0kqi5lo- X-Rocket-Received: from [192.168.1.9] (ThomasSkibo@71.139.173.243 with plain) by smtp108.sbc.mail.bf1.yahoo.com with SMTP; 26 Aug 2013 11:51:36 -0700 PDT Message-ID: <521BA3BF.10002@sbcglobal.net> Date: Mon, 26 Aug 2013 11:51:43 -0700 From: Thomas Skibo 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: My BB-Black boot failure References: <1377262426.1111.50.camel@revolution.hippie.lan> <1377526174.1111.138.camel@revolution.hippie.lan> In-Reply-To: <1377526174.1111.138.camel@revolution.hippie.lan> 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 List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Aug 2013 18:54:59 -0000 I've been experiencing this too on the Zedboard and I spent some time looking into it. In my case, arprequest() is overwriting past the end of an mbuf into the m_next field of the next one. Later, something tries to reference address 0x6401a8c0 which is actually the machine's IP address in network order. It looks like MH_ALIGN() used in arprequest() isn't working properly after the recent mbuf header changes. Here's the mbuf just after arprequest() has performed MH_ALIGN(). The m_data pointer is 0xc2c41de8 and the length is 0x1c. That puts the data over the edge into the next mbuf. The m_pkthdr appears to have been placed at 0xc2c41d18 (I think). It looks like the compiler inserted padding at 1d14 so MHLEN isn't correct. --Thomas XMD% mrd 0xc2c41d00 32 C2C41D00: 00000000 C2C41D04: 00000000 C2C41D08: C2C41DE8 (m_data) C2C41D0C: 0000001C (m_len) C2C41D10: 00000201 (m_type,m_flags) C2C41D14: 00000000 (?) C2C41D18: 00000000 (pkthdr.rcvif) C2C41D1C: 00000000 (pkthdr.tags) C2C41D20: 0000001C (pkthdr.len) C2C41D24: 00000000 C2C41D28: 00000000 C2C41D2C: 00000000 On 8/26/13 7:09 AM, Ian Lepore wrote: > On Mon, 2013-08-26 at 19:14 +0800, XiaoQI Ge wrote: >> I'm using the latest source code compiled kernel (r254898) >> Kernel panic after start >> >> Kernel entry at 0x80200100... >> Kernel args: (null) >> 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-CURRENT #2 r254898: Tue Aug 27 00:44:45 CST 2013 >> root@7axu.com:/crochet-freebsd/work/obj/arm.armv6/usr/src/sys/BB-Black arm >> FreeBSD clang version 3.3 (tags/RELEASE_33/final 183502) 20130610 >> WARNING: WITNESS option enabled, expect reduced performance. >> WARNING: DIAGNOSTIC option enabled, expect reduced performance. > >> [snip] > > > Several people are experiencing this address fault or similar ones, > sometimes in in_cksum() instead of so_receivegeneric(). > > It looks like the latest revision that I can build and boot the BB > without any trouble is r254777. > > The revision that actually breaks things appears to be r254807 (kudos to > Zbyszek Bodek for tracking it down to this rev), so you can boot using > r254806 but to get that rev to build you have to also apply the changes > from r254814. > > There was a large flurry of checkins over the past few days to get > things in before the cutoff for the 10.0 release. I have a feeling it > will be a few days before the dust settles and we get some fixes. > > -- Ian > > > _______________________________________________ > freebsd-arm@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" > -- -------- Thomas Skibo ThomasSkibo@sbcglobal.net From owner-freebsd-arm@FreeBSD.ORG Mon Aug 26 19:05:38 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id D776756F for ; Mon, 26 Aug 2013 19:05:38 +0000 (UTC) (envelope-from zbb@semihalf.com) Received: from mail-ea0-f181.google.com (mail-ea0-f181.google.com [209.85.215.181]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 6B22828B5 for ; Mon, 26 Aug 2013 19:05:37 +0000 (UTC) Received: by mail-ea0-f181.google.com with SMTP id d10so1797173eaj.40 for ; Mon, 26 Aug 2013 12:05:30 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:content-type:content-transfer-encoding; bh=ODY4wdYxX3LQnD6GYih9Q2Z0cvNHUCEhjqxkTZC+5v0=; b=PtPk/4rvnN9UwpE/AOg5CT9CA+8A/QWc5xcLjV4qZzK5yggGPoWGDOCTg5p1EAmfqo ips0bA5ND1tNjUgckJhFG+NA1ohbfyeJ96pp7d98pvZxSHSfvdg1xMkagtcJgXH62Wi4 MlaTNFMFRMN9bVHEC7lwVKeBYpERU2vZFur9LpOpN5Ph41vWCGsUNTRptcl8VNTTu17R nGajR5JoUGiAWz0NgZyffEMehJzXZhr+esBKwS9xl2YwB8DE5KVkdsuLFr3kqat1TGZX BNYvcwO41LYgc14Jp7QDoC0+jJ4Ee6bvYbG/sbGCBovFoXztIfvstePJhxG/wHoeN1wU WcyA== X-Gm-Message-State: ALoCoQnt3PgnG/jGAwI7DePNaosdJzJObNqw0jCKlqSYOqOl3FtOtNgEZdftfykFNTBuLVWI+LVu X-Received: by 10.14.122.132 with SMTP id t4mr28377621eeh.20.1377543930229; Mon, 26 Aug 2013 12:05:30 -0700 (PDT) Received: from [10.0.2.117] (cardhu.semihalf.com. [213.17.239.108]) by mx.google.com with ESMTPSA id m54sm23411255eex.2.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 26 Aug 2013 12:05:29 -0700 (PDT) Message-ID: <521BA6F6.3010308@semihalf.com> Date: Mon, 26 Aug 2013 21:05:26 +0200 From: Zbyszek Bodek Organization: Semihalf User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130803 Thunderbird/17.0.8 MIME-Version: 1.0 To: freebsd-arm@FreeBSD.org Subject: HEADS UP: Superpages support for ARMv6/v7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Alan Cox 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, 26 Aug 2013 19:05:38 -0000 Hello Everyone. I'm happy to announce that Superpages support for ARM has just been integrated to the FreeBSD HEAD: http://svnweb.freebsd.org/changeset/base/254918 This project was sponsored by The FreeBSD Foundation and Semihalf. It was developed with great support of Alan Cox (alc) who was also the technical reviewer of the code. Thank you very much Alan for all your help! I would also like to thank Grzegorz Bernacki (gber) and Rafal Jaworowski (raj) for mentoring and help with the code integration and all the people involved in testing of the patches and review. The code was tested on a quad-core, ARMv7, Marvell Armada XP SoC in SMP environment. Superpages is a feature that can increase TLB coverage and allow for efficient use of page table entries. Current implementation for ARM supports two page sizes: 4KB small pages (used as base pages) and 1MB sections (used as superpages). Superpages are created either directly by 1MB section insertion or as a result of promotion of 256 4KB pages. In both cases superpages creation and utilization depends on *sp_enabled* sysctl variable. By default, superpages support is disabled. In order to use this functionality one needs to set *vm.pmap.sp_enabled* tunable to non-zero value. This can be done either in loader.conf or by modifying *sp_enabled* variable in sys/arm/arm/pmap-v6.c . Statistics regarding superpages usage are available through: sysctl vm.pmap.section All ARMv6/v7-based platforms can take advantage from superpages, so please enable this feature on your ARM kernels. We will appreciate all your feedback regarding performance impact and general system behavior. Performance improvement should be visible in all tasks where intensive memory utilization is involved. GUPS (Giga Updates Per Second) benchmark can be used to show the difference in memory utilization efficiency with superpages enabled and disabled. GUPS src can be downloaded from here: http://people.freebsd.org/~raj/patches/arm/superpages/GUPS.tar.gz Exemplary GUPS results: -------------------------------------------------------------------- *superpages enabled* vm.pmap.section.promotions: 1024 vm.pmap.section.p_failures: 58 vm.pmap.section.mappings: 0 vm.pmap.section.demotions: 0 # ./gups Main table size = 2^27 = 134217728 words Number of updates = 536870912 CPU time used = 97.085938 seconds Real time used = 97.082504 seconds 0.005530048 Billion(10^9) Updates per second [GUP/s] vm.pmap.section.promotions: 2048 vm.pmap.section.p_failures: 58 vm.pmap.section.mappings: 0 vm.pmap.section.demotions: 0 * superpages disabled * Main table size = 2^27 = 134217728 words Number of updates = 536870912 CPU time used = 145.679688 seconds Real time used = 145.680798 seconds 0.003685255 Billion(10^9) Updates per second [GUP/s] -------------------------------------------------------------------- *Self host buildworld* World build time on Armada XP has shortened from 6h 36min to 5h 14min with superpages enabled. *Stress tests* stress --cpu 4 --io 4 --vm 2 --vm-bytes 800M Survived long time runs, large superpages creation ratio has been observed. *Swapping* No problems with swapping or system running under heavy load with shortage of memory have been observed. Please feel free to send your results. Best regards Zbigniew Bodek From owner-freebsd-arm@FreeBSD.ORG Mon Aug 26 19:56:32 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 70EDBF7D for ; Mon, 26 Aug 2013 19:56:32 +0000 (UTC) (envelope-from jiashiun@gmail.com) Received: from mail-oa0-x22f.google.com (mail-oa0-x22f.google.com [IPv6:2607:f8b0:4003:c02::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 3D4F12B92 for ; Mon, 26 Aug 2013 19:56:32 +0000 (UTC) Received: by mail-oa0-f47.google.com with SMTP id g12so4160385oah.20 for ; Mon, 26 Aug 2013 12:56:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=tux6blEnrXIaUujKsefa/MXTV8EMVUSZYuTGNLMXXJI=; b=ySCdJGMtQveYmlgya4gaHHT+v6hDZAKbn1zWmvRtOjtOX+/6Kzlpa716evJnJt4C6N qX+R5CmfyvwgpAo+ft6nhFacl+fJe+xNo0iEVLa8VLVo/n28PxMl7gQwSEDHydEoFUwp 7BScixghM9BwadP46Cfimo56Jj4eDftpb2uvKW3qQxcJ8xv1jqypWwravtmwZp6W+lnf 1ris3jTPcyNK++Zeo15iWnJixpFWyq6dBW/Coh2OdsQYYLBTU4TYgabwZ06r9DBSGhrN 0dwElRspEj35/wEURzCuYKnvpYlDR51Ns9uHV+pxtWrMHderTGV+cWXOVm+EML50LFXH irdQ== X-Received: by 10.182.227.227 with SMTP id sd3mr1673458obc.68.1377546991476; Mon, 26 Aug 2013 12:56:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.76.131.111 with HTTP; Mon, 26 Aug 2013 12:56:00 -0700 (PDT) In-Reply-To: References: <5218FBE2.2000907@m5p.com> From: Jia-Shiun Li Date: Tue, 27 Aug 2013 03:56:00 +0800 Message-ID: Subject: Re: Pretty good RPi version? To: Tim Kientzle Content-Type: text/plain; charset=UTF-8 Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Aug 2013 19:56:32 -0000 Today it seems to be worse... panic immediately after booting up if Ethernet connected: http://goo.gl/WPEBo8 If disconnect Ethernet, it can boot up. But it has many 'memory modified after free' message, and soon panics after running portsnap. http://goo.gl/3nHKNW Kernel version is FreeBSD 10.0-CURRENT #0 r254914: Tue Aug 27 00:42:02 CST 2013 Jia-Shiun. From owner-freebsd-arm@FreeBSD.ORG Mon Aug 26 20:19:01 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 8243193D for ; Mon, 26 Aug 2013 20:19:01 +0000 (UTC) (envelope-from ThomasSkibo@sbcglobal.net) Received: from nm10-vm3.access.bullet.mail.gq1.yahoo.com (nm10-vm3.access.bullet.mail.gq1.yahoo.com [216.39.63.68]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 4FEB32D5E for ; Mon, 26 Aug 2013 20:19:01 +0000 (UTC) Received: from [216.39.60.172] by nm10.access.bullet.mail.gq1.yahoo.com with NNFMP; 26 Aug 2013 20:18:54 -0000 Received: from [67.195.14.110] by tm8.access.bullet.mail.gq1.yahoo.com with NNFMP; 26 Aug 2013 20:18:54 -0000 Received: from [127.0.0.1] by smtp107.sbc.mail.gq1.yahoo.com with NNFMP; 26 Aug 2013 20:18:54 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sbcglobal.net; s=s1024; t=1377548334; bh=4SmSz7D0NW/VHAZEqS2YbEgvTLTP+VdnqpXBidEpVkU=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=q6J8Yv+p8ZVP1EMsYXiomaa7Gz11yO8mCS+hSDiqmnM88BR3aoCp4aCIn/96EuTFVkn0jyVNQBzBlWzUiF1b8znFLvyLWilKUm6ltGU4meixRXslhwxUI8xB1YTo0g2c99gVjGWv844beVkaVP87zoyOoUtuLxs/eVxO5R/GP3c= X-Yahoo-Newman-Id: 164798.41664.bm@smtp107.sbc.mail.gq1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: pcJHCwEVM1nAOly0KKvmwVYd5hugdrhijTLqnYQtEiQxuAa QmObkDqwJSW2m.WOwHMY1h1SIc88Zf4cnpuU6EFG4brhQ69T0EYNu5Wbf2gB 3asZGF48N9XXzOrIjri8hOWjSg5sbqoo3z2OC_aw0A5walqRnyvSMHubugOm 8jYFeeTH9yiDh7Aj1SRl55Beqb3MMSMttzuWzsT4WYIhRqHV.D2DsH1lqAUA y0BgwsbPy2W.adMEC2FOtxIn.j1BoX16A0uu.ykLbcPAJ_gwJICrp8WZWnq0 XEBLBUR1nTCKaF6GnvmIV06gXvDSqyyNeQpUFmfdEBT_ejf1OgMdaMVN2mgJ uXx31TCejrD997sXlkgWv4SwXmz4z4Bh2lHrQUSFPtGrrKbfV9gVevs8UqE4 n1fZw_mVFuvRiIlQqyN7c8.gPqiyMod6WoPglsv_YOLdjcb0WRA1ewHiI8Jo hKM3gewuXG9.Ewp2G5Mp7KO0Pb_X5OPPHH_F1xQuDZpckUTU65wMfIE_Jti. A.NipFzsTvJnQQDiYOTCudb3aLTBlZ_wYq86FfC_2lcmaEjHSTJI5Gs1e462 KrfSRJF35ftuPis6WNBmuBhxyVACvv7uZpKKnLDxbq3f__L1TNSh6k1.dHf5 mFqCwTmVKPH.lAoyV72YKR_cv.lHHcw7plANc9eusKRg3npKv1GsZiq0Oe53 qMQI- X-Yahoo-SMTP: tUxoRneswBA21azLM.3ybMESf0mC2bFhTbmt0VU5ervH0kqi5lo- X-Rocket-Received: from [192.168.1.9] (ThomasSkibo@71.139.173.243 with plain) by smtp107.sbc.mail.gq1.yahoo.com with SMTP; 26 Aug 2013 13:18:54 -0700 PDT Message-ID: <521BB837.7000009@sbcglobal.net> Date: Mon, 26 Aug 2013 13:19:03 -0700 From: Thomas Skibo 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: Jia-Shiun Li Subject: Re: Pretty good RPi version? References: <5218FBE2.2000907@m5p.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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: Mon, 26 Aug 2013 20:19:01 -0000 That's exactly like my crash. Notice that r0 is the IP address of the machine. The first ARP request corrupts an mbuf m_next pointer. I've patched sys/sys/mbuf.h just to get things working. I'm not sure what the real fix should be. Index: sys/sys/mbuf.h =================================================================== --- sys/sys/mbuf.h (revision 254911) +++ sys/sys/mbuf.h (working copy) @@ -92,8 +92,8 @@ struct mbuf *mh_nextpkt; /* next chain in queue/record */ caddr_t mh_data; /* location of data */ int32_t mh_len; /* amount of data in this mbuf */ - uint32_t mh_type:8, /* type of data in this mbuf */ - mh_flags:24; /* flags; see below */ + uint32_t mh_type, /* type of data in this mbuf */ + mh_flags; /* flags; see below */ }; /* On 8/26/13 12:56 PM, Jia-Shiun Li wrote: > Today it seems to be worse... > > panic immediately after booting up if Ethernet connected: > http://goo.gl/WPEBo8 > > If disconnect Ethernet, it can boot up. But it has many 'memory > modified after free' message, and soon panics after running portsnap. > http://goo.gl/3nHKNW > > Kernel version is > FreeBSD 10.0-CURRENT #0 r254914: Tue Aug 27 00:42:02 CST 2013 > > Jia-Shiun. > _______________________________________________ > freebsd-arm@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" > -- -------- Thomas Skibo ThomasSkibo@sbcglobal.net From owner-freebsd-arm@FreeBSD.ORG Mon Aug 26 20:57: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 AD77C252; Mon, 26 Aug 2013 20:57:20 +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 725832FB3; Mon, 26 Aug 2013 20:57:20 +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 1VE3qg-000BJ5-Or; Mon, 26 Aug 2013 20:57:19 +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 r7QKvGcs052096; Mon, 26 Aug 2013 14:57:16 -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: U2FsdGVkX183M/zxwR6+B3B7uS1F8qH+ Subject: ARM network trouble after recent mbuf changes From: Ian Lepore To: Andre Oppermann , freebsd-arm Content-Type: text/plain; charset="us-ascii" Date: Mon, 26 Aug 2013 14:57:16 -0600 Message-ID: <1377550636.1111.156.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port 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: Mon, 26 Aug 2013 20:57:20 -0000 This new thread pulls together info from several other threads and irc conversations, to summarize what we know right now for Andre in case the problem is directly related to the mbuf changes. It looks like ARM systems consistantly get address translation faults related to network operations during boot. Zbyszek Bodek bisected it down to r254807; revisions before that work, beginning with that one they don't. A representative dmesg appears below. The abort happens in in_cksum(), or sbappendaddr_locked(), or soreceive_generic(), depending on various kernel config options and what network operations happen first. Thomas Skibo reports: I've been experiencing this too on the Zedboard and I spent some time looking into it. In my case, arprequest() is overwriting past the end of an mbuf into the m_next field of the next one. Later, something tries to reference address 0x6401a8c0 which is actually the machine's IP address in network order. It looks like MH_ALIGN() used in arprequest() isn't working properly after the recent mbuf header changes. Here's the mbuf just after arprequest() has performed MH_ALIGN(). The m_data pointer is 0xc2c41de8 and the length is 0x1c. That puts the data over the edge into the next mbuf. The m_pkthdr appears to have been placed at 0xc2c41d18 (I think). It looks like the compiler inserted padding at 1d14 so MHLEN isn't correct. XMD% mrd 0xc2c41d00 32 C2C41D00: 00000000 C2C41D04: 00000000 C2C41D08: C2C41DE8 (m_data) C2C41D0C: 0000001C (m_len) C2C41D10: 00000201 (m_type,m_flags) C2C41D14: 00000000 (?) C2C41D18: 00000000 (pkthdr.rcvif) C2C41D1C: 00000000 (pkthdr.tags) C2C41D20: 0000001C (pkthdr.len) C2C41D24: 00000000 C2C41D28: 00000000 C2C41D2C: 00000000 Thomas also reports that removing the bitfield definitions, so that flags and type are two separate integers, works around the problem. Could this be something related to how bitfields are handled in EABI? A sample dmesg with the fault... 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-CURRENT #1 r254935: Mon Aug 26 14:32:21 MDT 2013 ilepore@revolution.hippie.lan:/local/build/staging/freebsd/bb/obj/arm.armv6/local/build/staging/freebsd/bb/src/sys/BB arm FreeBSD clang version 3.3 (tags/RELEASE_33/final 183502) 20130610 CPU: Cortex A8-r3 rev 2 (Cortex-A core) Supported features: ARM_ISA THUMB2 JAZELLE THUMBEE ARMv4 Security_Ext WB disabled EABT branch prediction enabled LoUU:2 LoC:2 LoUIS:1 Cache level 1: 32KB/64B 4-way data cache WT WB Read-Alloc 32KB/64B 4-way instruction cache Read-Alloc Cache level 2: 256KB/64B 8-way unified cache WT WB Read-Alloc Write-Alloc real memory = 268435456 (256 MB) avail memory = 256483328 (244 MB) Texas Instruments AM3358 Processor, Revision ES1.0 random device not loaded; using insecure entropy random: initialized simplebus0: on fdtbus0 aintc0: mem 0x48200000-0x48200fff on simplebus0 aintc0: Revision 5.0 ti_scm0: mem 0x44e10000-0x44e11fff on simplebus0 am335x_prcm0: mem 0x44e00000-0x44e012ff on simplebus0 am335x_prcm0: Clocks: System 24.0 MHz, CPU 720 MHz am335x_dmtimer0: mem 0x44e05000-0x44e05fff,0x44e31000-0x44e31fff,0x48040000-0x48040fff,0x48042000-0x48042fff,0x48044000-0x48044fff,0x48046000-0x48046fff,0x48048000-0x48048fff,0x4804a000-0x4804afff irq 66,67,68,69,92,93,94,95 on simplebus0 Timecounter "AM335x Timecounter" frequency 24000000 Hz quality 1000 Event timer "AM335x Eventtimer0" frequency 24000000 Hz quality 1000 gpio0: mem 0x44e07000-0x44e07fff,0x4804c000-0x4804cfff,0x481ac000-0x481acfff,0x481ae000-0x481aefff irq 96,97,98,99,32,33,62,63 on simplebus0 gpioc0: on gpio0 gpiobus0: on gpio0 uart0: mem 0x44e09000-0x44e09fff irq 72 on simplebus0 uart0: console (115384,n,8,1) ti_edma30: mem 0x49000000-0x490fffff,0x49800000-0x498fffff,0x49900000-0x499fffff,0x49a00000-0x49afffff irq 12,13,14 on simplebus0 ti_edma30: EDMA revision 40014c00 sdhci_ti0: mem 0x48060000-0x48060fff irq 64 on simplebus0 mmc0: on sdhci_ti0 cpsw0: <3-port Switch Ethernet Subsystem> mem 0x4a100000-0x4a103fff irq 40,41,42,43 on simplebus0 cpsw0: CPSW SS Version 1.12 (0) cpsw0: Initial queue size TX=128 RX=384 cpsw0: Ethernet address: 00:18:31:8e:c0:96 miibus0: on cpsw0 smscphy0: PHY 0 on miibus0 smscphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto iichb0: mem 0x44e0b000-0x44e0bfff irq 70 on simplebus0 iichb0: I2C revision 4.0 iicbus0: on iichb0 iic0: on iicbus0 am335x_pmic0: at addr 0x24 on iicbus0 am335x_pwm0: mem 0x48300000-0x483000ff,0x48300100-0x4830017f,0x48300180-0x483001ff,0x48300200-0x4830025f irq 86,58 on simplebus0 am335x_pwm1: mem 0x48302000-0x483020ff,0x48302100-0x4830217f,0x48302180-0x483021ff,0x48302200-0x4830225f irq 87,59 on simplebus0 am335x_pwm2: mem 0x48304000-0x483040ff,0x48304100-0x4830417f,0x48304180-0x483041ff,0x48304200-0x4830425f irq 88,60 on simplebus0 Timecounters tick every 10.000 msec mmcsd0: 8GB at mmc0 48.0MHz/4bit/65535-block am335x_pmic0: TPS65217B ver 1.1 powered by USB and AC Sending DHCP Discover packet from interface cpsw0 (00:18:31:8e:c0:96) cpsw0: link state changed to DOWN cpsw0: link state changed to UP Received DHCP Offer packet on cpsw0 from 172.22.42.240 (accepted) Sending DHCP Request packet from interface cpsw0 (00:18:31:8e:c0:96) Received DHCP Ack packet on cpsw0 from 172.22.42.240 (accepted) (got root path) cpsw0 at 172.22.42.234 server 172.22.42.240 boot file /bb/boot/kernel/kernel subnet mask 255.255.255.0 router 172.22.42.254 rootfs 172.22.42.240:/bb Adjusted interface cpsw0 vm_fault(0xc05b0820, 57405000, 1, 0) -> 1 Fatal kernel mode data abort: 'Translation Fault (S)' trapframe: 0xc05c1ae8 FSR=00000005, FAR=5740540c, spsr=20000093 r0 =c188d418, r1 =00000000, r2 =00000000, r3 =00000010 r4 =f02a16ac, r5 =ea2a16ac, r6 =c188d3e8, r7 =00000000 r8 =425443df, r9 =00000000, r10=00000014, r11=c188d40c r12=57405400, ssp=c05c1b3c, slr=c049d748, pc =c049d720 [ thread pid 0 tid 100000 ] Stopped at in_cksum+0x14: ldr r1, [r12, #0x00c] -- Ian From owner-freebsd-arm@FreeBSD.ORG Mon Aug 26 21:04: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 16C545B4 for ; Mon, 26 Aug 2013 21:04:56 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 46D81207E for ; Mon, 26 Aug 2013 21:04:54 +0000 (UTC) Received: (qmail 9768 invoked from network); 26 Aug 2013 21:47:02 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 26 Aug 2013 21:47:02 -0000 Message-ID: <521BC2F3.4050600@freebsd.org> Date: Mon, 26 Aug 2013 23:04:51 +0200 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Ian Lepore Subject: Re: ARM network trouble after recent mbuf changes References: <1377550636.1111.156.camel@revolution.hippie.lan> In-Reply-To: <1377550636.1111.156.camel@revolution.hippie.lan> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Aug 2013 21:04:56 -0000 On 26.08.2013 22:57, Ian Lepore wrote: > This new thread pulls together info from several other threads and irc > conversations, to summarize what we know right now for Andre in case the > problem is directly related to the mbuf changes. > > It looks like ARM systems consistantly get address translation faults > related to network operations during boot. Zbyszek Bodek bisected it > down to r254807; revisions before that work, beginning with that one > they don't. A representative dmesg appears below. The abort happens in > in_cksum(), or sbappendaddr_locked(), or soreceive_generic(), depending > on various kernel config options and what network operations happen > first. > > Thomas Skibo reports: > > I've been experiencing this too on the Zedboard and I spent some time > looking into it. > > In my case, arprequest() is overwriting past the end of an mbuf into the > m_next field of the next one. Later, something tries to reference > address 0x6401a8c0 which is actually the machine's IP address in network > order. It looks like MH_ALIGN() used in arprequest() isn't working > properly after the recent mbuf header changes. > > Here's the mbuf just after arprequest() has performed MH_ALIGN(). The > m_data pointer is 0xc2c41de8 and the length is 0x1c. That puts the data > over the edge into the next mbuf. The m_pkthdr appears to have been > placed at 0xc2c41d18 (I think). It looks like the compiler inserted > padding at 1d14 so MHLEN isn't correct. > > XMD% mrd 0xc2c41d00 32 > C2C41D00: 00000000 > C2C41D04: 00000000 > C2C41D08: C2C41DE8 (m_data) > C2C41D0C: 0000001C (m_len) > C2C41D10: 00000201 (m_type,m_flags) > C2C41D14: 00000000 (?) > C2C41D18: 00000000 (pkthdr.rcvif) > C2C41D1C: 00000000 (pkthdr.tags) > C2C41D20: 0000001C (pkthdr.len) > C2C41D24: 00000000 > C2C41D28: 00000000 > C2C41D2C: 00000000 > > Thomas also reports that removing the bitfield definitions, so that > flags and type are two separate integers, works around the problem. > > Could this be something related to how bitfields are handled in EABI? It could be. We do use bitfields since forever in ip.h for the IPv4 header too. Besides that, do all the ARM system with this problem use the same network interface type? -- Andre > A sample dmesg with the fault... > > 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-CURRENT #1 r254935: Mon Aug 26 14:32:21 MDT 2013 > > ilepore@revolution.hippie.lan:/local/build/staging/freebsd/bb/obj/arm.armv6/local/build/staging/freebsd/bb/src/sys/BB arm > FreeBSD clang version 3.3 (tags/RELEASE_33/final 183502) 20130610 > CPU: Cortex A8-r3 rev 2 (Cortex-A core) > Supported features: ARM_ISA THUMB2 JAZELLE THUMBEE ARMv4 Security_Ext > WB disabled EABT branch prediction enabled > LoUU:2 LoC:2 LoUIS:1 > Cache level 1: > 32KB/64B 4-way data cache WT WB Read-Alloc > 32KB/64B 4-way instruction cache Read-Alloc > Cache level 2: > 256KB/64B 8-way unified cache WT WB Read-Alloc Write-Alloc > real memory = 268435456 (256 MB) > avail memory = 256483328 (244 MB) > Texas Instruments AM3358 Processor, Revision ES1.0 > random device not loaded; using insecure entropy > random: initialized > simplebus0: on fdtbus0 > aintc0: mem 0x48200000-0x48200fff on > simplebus0 > aintc0: Revision 5.0 > ti_scm0: mem 0x44e10000-0x44e11fff on simplebus0 > am335x_prcm0: mem > 0x44e00000-0x44e012ff on simplebus0 > am335x_prcm0: Clocks: System 24.0 MHz, CPU 720 MHz > am335x_dmtimer0: mem > 0x44e05000-0x44e05fff,0x44e31000-0x44e31fff,0x48040000-0x48040fff,0x48042000-0x48042fff,0x48044000-0x48044fff,0x48046000-0x48046fff,0x48048000-0x48048fff,0x4804a000-0x4804afff irq 66,67,68,69,92,93,94,95 on simplebus0 > Timecounter "AM335x Timecounter" frequency 24000000 Hz quality 1000 > Event timer "AM335x Eventtimer0" frequency 24000000 Hz quality 1000 > gpio0: mem > 0x44e07000-0x44e07fff,0x4804c000-0x4804cfff,0x481ac000-0x481acfff,0x481ae000-0x481aefff irq 96,97,98,99,32,33,62,63 on simplebus0 > gpioc0: on gpio0 > gpiobus0: on gpio0 > uart0: mem 0x44e09000-0x44e09fff irq 72 on > simplebus0 > uart0: console (115384,n,8,1) > ti_edma30: mem > 0x49000000-0x490fffff,0x49800000-0x498fffff,0x49900000-0x499fffff,0x49a00000-0x49afffff irq 12,13,14 on simplebus0 > ti_edma30: EDMA revision 40014c00 > sdhci_ti0: mem 0x48060000-0x48060fff irq 64 on > simplebus0 > mmc0: on sdhci_ti0 > cpsw0: <3-port Switch Ethernet Subsystem> mem 0x4a100000-0x4a103fff irq > 40,41,42,43 on simplebus0 > cpsw0: CPSW SS Version 1.12 (0) > cpsw0: Initial queue size TX=128 RX=384 > cpsw0: Ethernet address: 00:18:31:8e:c0:96 > miibus0: on cpsw0 > smscphy0: PHY 0 on miibus0 > smscphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto > iichb0: mem 0x44e0b000-0x44e0bfff irq 70 on > simplebus0 > iichb0: I2C revision 4.0 > iicbus0: on iichb0 > iic0: on iicbus0 > am335x_pmic0: at addr 0x24 on iicbus0 > am335x_pwm0: mem > 0x48300000-0x483000ff,0x48300100-0x4830017f,0x48300180-0x483001ff,0x48300200-0x4830025f irq 86,58 on simplebus0 > am335x_pwm1: mem > 0x48302000-0x483020ff,0x48302100-0x4830217f,0x48302180-0x483021ff,0x48302200-0x4830225f irq 87,59 on simplebus0 > am335x_pwm2: mem > 0x48304000-0x483040ff,0x48304100-0x4830417f,0x48304180-0x483041ff,0x48304200-0x4830425f irq 88,60 on simplebus0 > Timecounters tick every 10.000 msec > mmcsd0: 8GB at mmc0 > 48.0MHz/4bit/65535-block > am335x_pmic0: TPS65217B ver 1.1 powered by USB and AC > Sending DHCP Discover packet from interface cpsw0 (00:18:31:8e:c0:96) > cpsw0: link state changed to DOWN > cpsw0: link state changed to UP > Received DHCP Offer packet on cpsw0 from 172.22.42.240 (accepted) > Sending DHCP Request packet from interface cpsw0 (00:18:31:8e:c0:96) > Received DHCP Ack packet on cpsw0 from 172.22.42.240 (accepted) (got > root path) > cpsw0 at 172.22.42.234 server 172.22.42.240 boot > file /bb/boot/kernel/kernel > subnet mask 255.255.255.0 router 172.22.42.254 rootfs 172.22.42.240:/bb > Adjusted interface cpsw0 > > vm_fault(0xc05b0820, 57405000, 1, 0) -> 1 > Fatal kernel mode data abort: 'Translation Fault (S)' > trapframe: 0xc05c1ae8 > FSR=00000005, FAR=5740540c, spsr=20000093 > r0 =c188d418, r1 =00000000, r2 =00000000, r3 =00000010 > r4 =f02a16ac, r5 =ea2a16ac, r6 =c188d3e8, r7 =00000000 > r8 =425443df, r9 =00000000, r10=00000014, r11=c188d40c > r12=57405400, ssp=c05c1b3c, slr=c049d748, pc =c049d720 > > [ thread pid 0 tid 100000 ] > Stopped at in_cksum+0x14: ldr r1, [r12, #0x00c] > > -- Ian > > > > From owner-freebsd-arm@FreeBSD.ORG Mon Aug 26 21:11:19 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 03FAB99E for ; Mon, 26 Aug 2013 21:11:19 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 5293C2109 for ; Mon, 26 Aug 2013 21:11:18 +0000 (UTC) Received: (qmail 9807 invoked from network); 26 Aug 2013 21:53:26 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 26 Aug 2013 21:53:26 -0000 Message-ID: <521BC472.7040804@freebsd.org> Date: Mon, 26 Aug 2013 23:11:14 +0200 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Ian Lepore Subject: Re: ARM network trouble after recent mbuf changes References: <1377550636.1111.156.camel@revolution.hippie.lan> In-Reply-To: <1377550636.1111.156.camel@revolution.hippie.lan> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Aug 2013 21:11:19 -0000 On 26.08.2013 22:57, Ian Lepore wrote: > This new thread pulls together info from several other threads and irc > conversations, to summarize what we know right now for Andre in case the > problem is directly related to the mbuf changes. > > It looks like ARM systems consistantly get address translation faults > related to network operations during boot. Zbyszek Bodek bisected it > down to r254807; revisions before that work, beginning with that one > they don't. A representative dmesg appears below. The abort happens in > in_cksum(), or sbappendaddr_locked(), or soreceive_generic(), depending > on various kernel config options and what network operations happen > first. > > Thomas Skibo reports: > > I've been experiencing this too on the Zedboard and I spent some time > looking into it. > > In my case, arprequest() is overwriting past the end of an mbuf into the > m_next field of the next one. Later, something tries to reference > address 0x6401a8c0 which is actually the machine's IP address in network > order. It looks like MH_ALIGN() used in arprequest() isn't working > properly after the recent mbuf header changes. > > Here's the mbuf just after arprequest() has performed MH_ALIGN(). The > m_data pointer is 0xc2c41de8 and the length is 0x1c. That puts the data > over the edge into the next mbuf. The m_pkthdr appears to have been > placed at 0xc2c41d18 (I think). It looks like the compiler inserted > padding at 1d14 so MHLEN isn't correct. > > XMD% mrd 0xc2c41d00 32 > C2C41D00: 00000000 > C2C41D04: 00000000 > C2C41D08: C2C41DE8 (m_data) > C2C41D0C: 0000001C (m_len) > C2C41D10: 00000201 (m_type,m_flags) > C2C41D14: 00000000 (?) > C2C41D18: 00000000 (pkthdr.rcvif) > C2C41D1C: 00000000 (pkthdr.tags) > C2C41D20: 0000001C (pkthdr.len) > C2C41D24: 00000000 > C2C41D28: 00000000 > C2C41D2C: 00000000 > > Thomas also reports that removing the bitfield definitions, so that > flags and type are two separate integers, works around the problem. > > Could this be something related to how bitfields are handled in EABI? Can you try this patch see check if it makes a difference on the bitfield? -- Andre Index: sys/mbuf.h =================================================================== --- sys/mbuf.h (revision 254936) +++ sys/mbuf.h (working copy) @@ -94,7 +94,7 @@ int32_t mh_len; /* amount of data in this mbuf */ uint32_t mh_type:8, /* type of data in this mbuf */ mh_flags:24; /* flags; see below */ -}; +} __packed; /* * Packet tag structure (see below for details). @@ -169,7 +169,7 @@ (struct mbuf *, void *, void *); void *ext_arg1; /* optional argument pointer */ void *ext_arg2; /* optional argument pointer */ -}; +} __packed; /* * The core of the mbuf object along with some shortcut defines for practical From owner-freebsd-arm@FreeBSD.ORG Mon Aug 26 21:41: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 E8EA6550; Mon, 26 Aug 2013 21:41:44 +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 BF1172328; Mon, 26 Aug 2013 21:41:44 +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 1VE4Xf-000E9K-Hn; Mon, 26 Aug 2013 21:41:43 +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 r7QLfelr052158; Mon, 26 Aug 2013 15:41:40 -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+Nrlfe6JdEGJMtZ6NEFNF3 Subject: Re: ARM network trouble after recent mbuf changes From: Ian Lepore To: Andre Oppermann In-Reply-To: <521BC472.7040804@freebsd.org> References: <1377550636.1111.156.camel@revolution.hippie.lan> <521BC472.7040804@freebsd.org> Content-Type: text/plain; charset="us-ascii" Date: Mon, 26 Aug 2013 15:41:40 -0600 Message-ID: <1377553300.1111.157.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Aug 2013 21:41:45 -0000 On Mon, 2013-08-26 at 23:11 +0200, Andre Oppermann wrote: > On 26.08.2013 22:57, Ian Lepore wrote: > > This new thread pulls together info from several other threads and irc > > conversations, to summarize what we know right now for Andre in case the > > problem is directly related to the mbuf changes. > > > > It looks like ARM systems consistantly get address translation faults > > related to network operations during boot. Zbyszek Bodek bisected it > > down to r254807; revisions before that work, beginning with that one > > they don't. A representative dmesg appears below. The abort happens in > > in_cksum(), or sbappendaddr_locked(), or soreceive_generic(), depending > > on various kernel config options and what network operations happen > > first. > > > > Thomas Skibo reports: > > > > I've been experiencing this too on the Zedboard and I spent some time > > looking into it. > > > > In my case, arprequest() is overwriting past the end of an mbuf into the > > m_next field of the next one. Later, something tries to reference > > address 0x6401a8c0 which is actually the machine's IP address in network > > order. It looks like MH_ALIGN() used in arprequest() isn't working > > properly after the recent mbuf header changes. > > > > Here's the mbuf just after arprequest() has performed MH_ALIGN(). The > > m_data pointer is 0xc2c41de8 and the length is 0x1c. That puts the data > > over the edge into the next mbuf. The m_pkthdr appears to have been > > placed at 0xc2c41d18 (I think). It looks like the compiler inserted > > padding at 1d14 so MHLEN isn't correct. > > > > XMD% mrd 0xc2c41d00 32 > > C2C41D00: 00000000 > > C2C41D04: 00000000 > > C2C41D08: C2C41DE8 (m_data) > > C2C41D0C: 0000001C (m_len) > > C2C41D10: 00000201 (m_type,m_flags) > > C2C41D14: 00000000 (?) > > C2C41D18: 00000000 (pkthdr.rcvif) > > C2C41D1C: 00000000 (pkthdr.tags) > > C2C41D20: 0000001C (pkthdr.len) > > C2C41D24: 00000000 > > C2C41D28: 00000000 > > C2C41D2C: 00000000 > > > > Thomas also reports that removing the bitfield definitions, so that > > flags and type are two separate integers, works around the problem. > > > > Could this be something related to how bitfields are handled in EABI? > > Can you try this patch see check if it makes a difference on the bitfield? > Nope, that made no difference for me, same abort in the same place. -- Ian From owner-freebsd-arm@FreeBSD.ORG Mon Aug 26 22:14:36 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 47DD9CC7 for ; Mon, 26 Aug 2013 22:14:36 +0000 (UTC) (envelope-from ThomasSkibo@sbcglobal.net) Received: from nm4-vm8.access.bullet.mail.gq1.yahoo.com (nm4-vm8.access.bullet.mail.gq1.yahoo.com [216.39.63.212]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id E506D24DD for ; Mon, 26 Aug 2013 22:14:35 +0000 (UTC) Received: from [216.39.60.176] by nm4.access.bullet.mail.gq1.yahoo.com with NNFMP; 26 Aug 2013 22:08:06 -0000 Received: from [67.195.14.95] by tm12.access.bullet.mail.gq1.yahoo.com with NNFMP; 26 Aug 2013 22:08:06 -0000 Received: from [127.0.0.1] by smtp110.sbc.mail.gq1.yahoo.com with NNFMP; 26 Aug 2013 22:08:06 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sbcglobal.net; s=s1024; t=1377554886; bh=XDi1sRFZdyDkaZF6eWc+JFlVMVbX8wi8vO1krO94ot8=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=50Yw4ZehTgnMO1dVBsdU98NbaAF693Qx7oHIf56V8g+/iAEqv6u7LzpSSx9DxkQypn/xKkJJsrDUnieNEX0oHHBMoDRLuM5GpJfhOjB2objOaNQvRvqKvchOJMT5mZ7ySLg3TMm2Vf4nj/M10QXCvhS4aaKbhD4fTP0TLwVvEnU= X-Yahoo-Newman-Id: 54818.25566.bm@smtp110.sbc.mail.gq1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: l6ql6FoVM1kY39r2JRZOs4WCSOXsWletiABvRFRa7g1WuiL A3u9WTOrKjr9Z5lNE0eCuYV0ETWPSdhpEMPsbklWS73xcOJG7qKyAvLebgP2 Zqx86mfVeDNZm5Uy1aw0QPwWHVXm_YsINlEDAjy86Thf89qWKFoHwFGkAdVt Xf.JfeZBwldGKk7xAy8E448eKmpYZlphu_xxKEiaSw3j7UwlRVJRSRySd2ZH 36y8Gbx1t9pZf1U.c8vegIgF04zgnmxrjpsN0nsehpUnPgXRXn74Zt4zQeFf Hf6ObNKvtEPKnq8fsaL3kweQ97k3Cn3uwlce0z5.aFltYp3duF5Jd0rf80Qd pvxErAIXVx9Zb9PjmSxwOKH4pdpF6udw3NumuDid.S9Gu51e.zgE.cTJDHq7 91MIYURLeRC9M.Wv4zevL.QqNoemMx7jJOvK9sBFVS4fP4Jx.SppteuRSfpn J85LID6Cjfdal4vGY.2O8vMT5.ZlkFjXhGU.UKllnHPbKRGflgYS.w9f5cMU 0O._PPAQqSr7dI1CmtUz3ZuY1jkAojju0TyS5rOwhh13QYm7Ih.DkEle4jOj gEhoNj_vyyxPH X-Yahoo-SMTP: tUxoRneswBA21azLM.3ybMESf0mC2bFhTbmt0VU5ervH0kqi5lo- X-Rocket-Received: from [192.168.1.9] (ThomasSkibo@71.139.173.243 with plain) by smtp110.sbc.mail.gq1.yahoo.com with SMTP; 26 Aug 2013 15:08:06 -0700 PDT Message-ID: <521BD1C8.8000500@sbcglobal.net> Date: Mon, 26 Aug 2013 15:08:08 -0700 From: Thomas Skibo 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: Andre Oppermann Subject: Re: ARM network trouble after recent mbuf changes References: <1377550636.1111.156.camel@revolution.hippie.lan> <521BC2F3.4050600@freebsd.org> In-Reply-To: <521BC2F3.4050600@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: 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: Mon, 26 Aug 2013 22:14:36 -0000 On 8/26/13 2:04 PM, Andre Oppermann wrote: > On 26.08.2013 22:57, Ian Lepore wrote: >> >> Could this be something related to how bitfields are handled in EABI? > > It could be. We do use bitfields since forever in ip.h for the IPv4 header > too. I think the bitfields are fine and it's doing what you expect: struct m_hdr is five words long. I think what's happening is that the compiler pads the struct pkthdr in an mbuf to 64 bits. Because MLEN doesn't take into account that padding, it is too big by 4. My work-around fixes it by making struct m_hdr six words instead of five. > > Besides that, do all the ARM system with this problem use the same network > interface type? > The same driver? No. Zynq/Zedboard has a unique ethernet driver and it's seeing the problem I tried your patch (adding __packed to a few structs) and it didn't work. Maybe pack struct mbuf ? --Thomas -- -------- Thomas Skibo ThomasSkibo@sbcglobal.net From owner-freebsd-arm@FreeBSD.ORG Mon Aug 26 22:28:13 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 0D28821D for ; Mon, 26 Aug 2013 22:28:13 +0000 (UTC) (envelope-from ThomasSkibo@sbcglobal.net) Received: from nm22-vm1.access.bullet.mail.bf1.yahoo.com (nm22-vm1.access.bullet.mail.bf1.yahoo.com [216.109.115.144]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id A231A25A9 for ; Mon, 26 Aug 2013 22:28:12 +0000 (UTC) Received: from [66.196.81.156] by nm22.access.bullet.mail.bf1.yahoo.com with NNFMP; 26 Aug 2013 22:22:39 -0000 Received: from [98.139.221.48] by tm2.access.bullet.mail.bf1.yahoo.com with NNFMP; 26 Aug 2013 22:22:39 -0000 Received: from [127.0.0.1] by smtp101.sbc.mail.bf1.yahoo.com with NNFMP; 26 Aug 2013 22:22:39 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sbcglobal.net; s=s1024; t=1377555759; bh=hPhnzDTnKnfJJpUUoCHp6k6NZI6bhfwS3/2w2KHiPgs=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=4yv5mGMbofMQ3J3Mce4HzusifCTqA3v2+D+w01BZgZ1jl3P4sb8ZF3Nb7DcZrqZP5/WeRkBxZyJ0XYS01wokJQFL1ZB9UQ9dXprUVU2zXyTUDJi3jzZM5W3TPePSuG+yEXE8vzCXc/pNBZP9103rnks9agLXhOXVLbUL6gkT1b0= X-Yahoo-Newman-Id: 534893.85420.bm@smtp101.sbc.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: gHgTueEVM1nxmq0zs9ujMTZgRlXcDx68Snkh.njnW_bH.xz wxkTb9R_MB_Xr77q6huhgd135G2pLQdyl4ORzbscMjy2sVX3u_hdfE4Vzy.9 4zJj93U8HVObFq5hr_GcqOkkDwY39m7WtxVf3f5TL00n.HRiEYCQ8b5GgZuL nUY.rZAxmoitGC8yypAF8ZMHKOQ1bkLZoRvGSoX.bnmVOAx8mdaAIHEj3Ka5 M_bzleWni40Q01YhT16.QvjHOHuh6tGd5MFnL28Bc85e_jd7s0Ks3G82WS03 .shtLz1MT01ttjV9K3LaTsfxKhq2CTHwy0JV9CIc_mHjGidL8AfXDsqBfs3z cijFPgDyqumkNs4qQpcGAyH9LF9PBYhuZgCg0pY1kNNeeChCxQxO1LbIQH8i IOIj7RNXclC68yTJzwMBsn_kceSDiRynt0.4arMxvWlJf8zT.2AAvOY77usQ nTyJTNW9XBth2oq2vjv8Oqe3l1tkWfVaOM16Ecejtwnkb1ILZokFoCdDfUCd PmZNcfs5KngCr.iD0aRsOhw6gF_IT82Qnhoe7fj9BqiLFXl8lJAvS0cSB.nw iFEK5F7_N X-Yahoo-SMTP: tUxoRneswBA21azLM.3ybMESf0mC2bFhTbmt0VU5ervH0kqi5lo- X-Rocket-Received: from [192.168.1.9] (ThomasSkibo@71.139.173.243 with plain) by smtp101.sbc.mail.bf1.yahoo.com with SMTP; 26 Aug 2013 15:22:39 -0700 PDT Message-ID: <521BD531.4090104@sbcglobal.net> Date: Mon, 26 Aug 2013 15:22:41 -0700 From: Thomas Skibo 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: Andre Oppermann Subject: Re: ARM network trouble after recent mbuf changes References: <1377550636.1111.156.camel@revolution.hippie.lan> <521BC472.7040804@freebsd.org> In-Reply-To: <521BC472.7040804@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Aug 2013 22:28:13 -0000 On 8/26/13 2:11 PM, Andre Oppermann wrote: > > Can you try this patch see check if it makes a difference on the bitfield? > Actually, this works for me. But, I'm worried that somewhere else something is going to trip over a struct pkthdr not being 64-bit aligned. There are several 64-bit fields in there. --Thomas root@ashbury:/usr/src/sys/sys # svn diff mbuf.h Index: mbuf.h =================================================================== --- mbuf.h (revision 254889) +++ mbuf.h (working copy) @@ -94,7 +94,7 @@ int32_t mh_len; /* amount of data in this mbuf */ uint32_t mh_type:8, /* type of data in this mbuf */ mh_flags:24; /* flags; see below */ -}; +} __packed; /* * Packet tag structure (see below for details). @@ -169,7 +169,7 @@ (struct mbuf *, void *, void *); void *ext_arg1; /* optional argument pointer */ void *ext_arg2; /* optional argument pointer */ -}; +} __packed; /* * The core of the mbuf object along with some shortcut defines for practical @@ -187,7 +187,7 @@ } MH; char M_databuf[MLEN]; /* !M_PKTHDR, !M_EXT */ } M_dat; -}; +} __packed; #define m_next m_hdr.mh_next #define m_len m_hdr.mh_len -- -------- Thomas Skibo ThomasSkibo@sbcglobal.net From owner-freebsd-arm@FreeBSD.ORG Mon Aug 26 22:38: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 1CE8E6F3; Mon, 26 Aug 2013 22:38:42 +0000 (UTC) (envelope-from tuexen@freebsd.org) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id A07D32647; Mon, 26 Aug 2013 22:38:41 +0000 (UTC) Received: from [192.168.1.200] (p508F3DB2.dip0.t-ipconnect.de [80.143.61.178]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 232701C0C0692; Tue, 27 Aug 2013 00:38:37 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Subject: Re: ARM network trouble after recent mbuf changes From: Michael Tuexen In-Reply-To: <521BD531.4090104@sbcglobal.net> Date: Tue, 27 Aug 2013 00:38:35 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1377550636.1111.156.camel@revolution.hippie.lan> <521BC472.7040804@freebsd.org> <521BD531.4090104@sbcglobal.net> To: Thomas Skibo X-Mailer: Apple Mail (2.1508) Cc: freebsd-arm , Andre Oppermann 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, 26 Aug 2013 22:38:42 -0000 I did some tests with a small program. Having in struct pkthdr 64 bit = entities results in a 64 bit alignment when used in struct mbuf. Using __packed for struct mbuf, removes the padding. Best regards Michael On Aug 27, 2013, at 12:22 AM, Thomas Skibo = wrote: >=20 >=20 > On 8/26/13 2:11 PM, Andre Oppermann wrote: >>=20 >> Can you try this patch see check if it makes a difference on the = bitfield? >>=20 >=20 > Actually, this works for me. But, I'm worried that somewhere else = something is going to trip over a struct pkthdr not being 64-bit = aligned. There are several 64-bit fields in there. >=20 >=20 > --Thomas >=20 > root@ashbury:/usr/src/sys/sys # svn diff mbuf.h > Index: mbuf.h > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- mbuf.h (revision 254889) > +++ mbuf.h (working copy) > @@ -94,7 +94,7 @@ > int32_t mh_len; /* amount of data in this mbuf = */ > uint32_t mh_type:8, /* type of data in this mbuf */ > mh_flags:24; /* flags; see below */ > -}; > +} __packed; >=20 > /* > * Packet tag structure (see below for details). > @@ -169,7 +169,7 @@ > (struct mbuf *, void *, void *); > void *ext_arg1; /* optional argument pointer */ > void *ext_arg2; /* optional argument pointer */ > -}; > +} __packed; >=20 > /* > * The core of the mbuf object along with some shortcut defines for = practical > @@ -187,7 +187,7 @@ > } MH; > char M_databuf[MLEN]; /* !M_PKTHDR, = !M_EXT */ > } M_dat; > -}; > +} __packed; > #define m_next m_hdr.mh_next > #define m_len m_hdr.mh_len >=20 >=20 > --=20 > -------- > Thomas Skibo > ThomasSkibo@sbcglobal.net >=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 From owner-freebsd-arm@FreeBSD.ORG Tue Aug 27 05:52: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 8829B723; Tue, 27 Aug 2013 05:52:28 +0000 (UTC) (envelope-from hps@bitfrost.no) Received: from mta.bitpro.no (mta.bitpro.no [92.42.64.202]) by mx1.freebsd.org (Postfix) with ESMTP id 443222CD2; Tue, 27 Aug 2013 05:52:28 +0000 (UTC) Received: from mail.lockless.no (mail.lockless.no [46.29.221.38]) by mta.bitpro.no (Postfix) with ESMTP id 3135D7A232; Tue, 27 Aug 2013 07:52:26 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mail.lockless.no (Postfix) with ESMTP id 89D148F45D5; Tue, 27 Aug 2013 07:52:38 +0200 (CEST) X-Virus-Scanned: by amavisd-new-2.6.4 (20090625) (Debian) at lockless.no Received: from mail.lockless.no ([127.0.0.1]) by localhost (mail.lockless.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ctvvQ2-Aumkn; Tue, 27 Aug 2013 07:52:38 +0200 (CEST) Received: from laptop015.home.selasky.org (cm-176.74.213.204.customer.telag.net [176.74.213.204]) by mail.lockless.no (Postfix) with ESMTPSA id 8576F8F45D4; Tue, 27 Aug 2013 07:52:37 +0200 (CEST) Message-ID: <521C3EE4.80801@bitfrost.no> Date: Tue, 27 Aug 2013 07:53:40 +0200 From: Hans Petter Selasky Organization: Bitfrost A/S User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130522 Thunderbird/17.0.6 MIME-Version: 1.0 To: Michael Tuexen Subject: Re: ARM network trouble after recent mbuf changes References: <1377550636.1111.156.camel@revolution.hippie.lan> <521BC472.7040804@freebsd.org> <521BD531.4090104@sbcglobal.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-arm , Andre Oppermann 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, 27 Aug 2013 05:52:28 -0000 On 08/27/13 00:38, Michael Tuexen wrote: > I did some tests with a small program. Having in struct pkthdr 64 bit entities > results in a 64 bit alignment when used in struct mbuf. Using __packed > for struct mbuf, removes the padding. Hi, Maybe you could use __aligned(8) instead, and account for the extra padding on all platforms? Packed has other disadvantages on ARM platforms when accessing the structures, like that non-aligned access is possible, and that it is sometimes slower than aligned access. --HPS From owner-freebsd-arm@FreeBSD.ORG Tue Aug 27 06:30: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 39B4BC82; Tue, 27 Aug 2013 06:30:32 +0000 (UTC) (envelope-from tuexen@freebsd.org) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id C07C52E7A; Tue, 27 Aug 2013 06:30:31 +0000 (UTC) Received: from [192.168.1.200] (p508F3337.dip0.t-ipconnect.de [80.143.51.55]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 4FF7C1C0C0692; Tue, 27 Aug 2013 08:30:28 +0200 (CEST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Subject: Re: ARM network trouble after recent mbuf changes From: Michael Tuexen In-Reply-To: <521C3EE4.80801@bitfrost.no> Date: Tue, 27 Aug 2013 08:30:27 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <3F762A16-3760-4FAA-B547-27529032AFEA@freebsd.org> References: <1377550636.1111.156.camel@revolution.hippie.lan> <521BC472.7040804@freebsd.org> <521BD531.4090104@sbcglobal.net> <521C3EE4.80801@bitfrost.no> To: Hans Petter Selasky X-Mailer: Apple Mail (2.1508) Cc: freebsd-arm , Andre Oppermann 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, 27 Aug 2013 06:30:32 -0000 On Aug 27, 2013, at 7:53 AM, Hans Petter Selasky = wrote: > On 08/27/13 00:38, Michael Tuexen wrote: >> I did some tests with a small program. Having in struct pkthdr 64 bit = entities >> results in a 64 bit alignment when used in struct mbuf. Using = __packed >> for struct mbuf, removes the padding. >=20 >=20 > Hi, >=20 > Maybe you could use __aligned(8) instead, and account for the extra = padding on all platforms? Packed has other disadvantages on ARM = platforms when accessing the structures, like that non-aligned access is = possible, and that it is sometimes slower than aligned access. Isn't there a performance penalty when accessing 64-bit entities not = being 64-bit aligned? If that is the case, wouldn't it make sense to add a 4 byte = padding to struct m_hdr for ILP32? Then the problem should go away... We could also get rid of the 64 bit alignment by not having 64-bit = entities in struct pkthdr. Removing sixtyfour should be easy. However, we now have = also uint64_t csum_flags. Best regards Michael >=20 > --HPS >=20 >=20 From owner-freebsd-arm@FreeBSD.ORG Tue Aug 27 06:53:19 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 4BA1C28D for ; Tue, 27 Aug 2013 06:53:19 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id B21E52FAA for ; Tue, 27 Aug 2013 06:53:18 +0000 (UTC) Received: (qmail 11749 invoked from network); 27 Aug 2013 07:35:21 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 27 Aug 2013 07:35:21 -0000 Message-ID: <521C4CD9.4050308@freebsd.org> Date: Tue, 27 Aug 2013 08:53:13 +0200 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Thomas Skibo Subject: Re: ARM network trouble after recent mbuf changes References: <1377550636.1111.156.camel@revolution.hippie.lan> <521BC472.7040804@freebsd.org> <521BD531.4090104@sbcglobal.net> In-Reply-To: <521BD531.4090104@sbcglobal.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Aug 2013 06:53:19 -0000 On 27.08.2013 00:22, Thomas Skibo wrote: > On 8/26/13 2:11 PM, Andre Oppermann wrote: >> >> Can you try this patch see check if it makes a difference on the bitfield? > > Actually, this works for me. But, I'm worried that somewhere else something is going to trip over a > struct pkthdr not being 64-bit aligned. There are several 64-bit fields in there. The problem is the disconnect between the definition of MLEN and MHLEN and the effective size/padding of struct mbuf. That's the true bug. On LP64 all is fine. On i386 it turns out to be fine too because doesn't care. MLEN and MHLEN are incorrectly derived. In fact they should be derived from stuct mbuf where this padding would be taking into account. However the way it is structured right now it that would create a circular dependency. Please try the patch below to confirm. If it fixes your problem for now I'm going to commit as an immediate fix while searching for a better long term stable solution. -- Andre Index: sys/mbuf.h =================================================================== --- sys/mbuf.h (revision 254953) +++ sys/mbuf.h (working copy) @@ -94,6 +94,9 @@ int32_t mh_len; /* amount of data in this mbuf */ uint32_t mh_type:8, /* type of data in this mbuf */ mh_flags:24; /* flags; see below */ +#if defined(__ILP32__) + uint32_t mh_pad; /* pad to 64 bit alignment */ +#endif }; /* From owner-freebsd-arm@FreeBSD.ORG Tue Aug 27 06:53: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 26D0E2CB for ; Tue, 27 Aug 2013 06:53:29 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 8B7162FB0 for ; Tue, 27 Aug 2013 06:53:28 +0000 (UTC) Received: (qmail 11753 invoked from network); 27 Aug 2013 07:35:31 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 27 Aug 2013 07:35:31 -0000 Message-ID: <521C4CE3.9080400@freebsd.org> Date: Tue, 27 Aug 2013 08:53:23 +0200 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Michael Tuexen Subject: Re: ARM network trouble after recent mbuf changes References: <1377550636.1111.156.camel@revolution.hippie.lan> <521BC472.7040804@freebsd.org> <521BD531.4090104@sbcglobal.net> <521C3EE4.80801@bitfrost.no> <3F762A16-3760-4FAA-B547-27529032AFEA@freebsd.org> In-Reply-To: <3F762A16-3760-4FAA-B547-27529032AFEA@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Aug 2013 06:53:29 -0000 On 27.08.2013 08:30, Michael Tuexen wrote: > On Aug 27, 2013, at 7:53 AM, Hans Petter Selasky wrote: > >> On 08/27/13 00:38, Michael Tuexen wrote: >>> I did some tests with a small program. Having in struct pkthdr 64 bit entities >>> results in a 64 bit alignment when used in struct mbuf. Using __packed >>> for struct mbuf, removes the padding. >> >> >> Hi, >> >> Maybe you could use __aligned(8) instead, and account for the extra padding on all platforms? Packed has other disadvantages on ARM platforms when accessing the structures, like that non-aligned access is possible, and that it is sometimes slower than aligned access. > Isn't there a performance penalty when accessing 64-bit entities not being 64-bit > aligned? If that is the case, wouldn't it make sense to add a 4 byte padding to > struct m_hdr for ILP32? Then the problem should go away... Either that or define MLEN and MHLEN in a way that actually reflects the true size of what they are representing. The latter is the true bug. > We could also get rid of the 64 bit alignment by not having 64-bit entities in > struct pkthdr. Removing sixtyfour should be easy. However, we now have also > uint64_t csum_flags. Yes, the 64 bit fields are to be used to store packet associated information on its way through the stack. Reducing it to 32 bits would somewhat defeat their purpose. -- Andre From owner-freebsd-arm@FreeBSD.ORG Tue Aug 27 06:58: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 C5E70370; Tue, 27 Aug 2013 06:58:34 +0000 (UTC) (envelope-from tuexen@freebsd.org) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 587442FE1; Tue, 27 Aug 2013 06:58:34 +0000 (UTC) Received: from [10.0.1.102] (unknown [212.201.121.94]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id C759E1C0C0692; Tue, 27 Aug 2013 08:58:32 +0200 (CEST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Subject: Re: ARM network trouble after recent mbuf changes From: Michael Tuexen In-Reply-To: <521C4CE3.9080400@freebsd.org> Date: Tue, 27 Aug 2013 08:58:42 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <627451FE-4F20-4E4D-9B24-59E0F340EF75@freebsd.org> References: <1377550636.1111.156.camel@revolution.hippie.lan> <521BC472.7040804@freebsd.org> <521BD531.4090104@sbcglobal.net> <521C3EE4.80801@bitfrost.no> <3F762A16-3760-4FAA-B547-27529032AFEA@freebsd.org> <521C4CE3.9080400@freebsd.org> To: Andre Oppermann 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: Tue, 27 Aug 2013 06:58:34 -0000 On Aug 27, 2013, at 8:53 AM, Andre Oppermann wrote: > On 27.08.2013 08:30, Michael Tuexen wrote: >> On Aug 27, 2013, at 7:53 AM, Hans Petter Selasky = wrote: >>=20 >>> On 08/27/13 00:38, Michael Tuexen wrote: >>>> I did some tests with a small program. Having in struct pkthdr 64 = bit entities >>>> results in a 64 bit alignment when used in struct mbuf. Using = __packed >>>> for struct mbuf, removes the padding. >>>=20 >>>=20 >>> Hi, >>>=20 >>> Maybe you could use __aligned(8) instead, and account for the extra = padding on all platforms? Packed has other disadvantages on ARM = platforms when accessing the structures, like that non-aligned access is = possible, and that it is sometimes slower than aligned access. >> Isn't there a performance penalty when accessing 64-bit entities not = being 64-bit >> aligned? If that is the case, wouldn't it make sense to add a 4 byte = padding to >> struct m_hdr for ILP32? Then the problem should go away... >=20 > Either that or define MLEN and MHLEN in a way that actually reflects = the true > size of what they are representing. The latter is the true bug. Correct. There is the hidden assumption that there is no padding. Maybe = you can put that in a comment... We could also have some code (maybe under INVARIANTS) where we check = that an struct mbuf has the size MSIZE and panic if not. This would make things clearer if the problem happens again. >=20 >> We could also get rid of the 64 bit alignment by not having 64-bit = entities in >> struct pkthdr. Removing sixtyfour should be easy. However, we now = have also >> uint64_t csum_flags. >=20 > Yes, the 64 bit fields are to be used to store packet associated = information > on its way through the stack. Reducing it to 32 bits would somewhat = defeat > their purpose. I completely agree... >=20 > --=20 > Andre >=20 >=20 From owner-freebsd-arm@FreeBSD.ORG Tue Aug 27 07:02: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 85F19417; Tue, 27 Aug 2013 07:02:15 +0000 (UTC) (envelope-from tuexen@freebsd.org) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 1BD742069; Tue, 27 Aug 2013 07:02:15 +0000 (UTC) Received: from [10.0.1.102] (unknown [212.201.121.94]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 963A61C0C0692; Tue, 27 Aug 2013 09:02:13 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Subject: Re: ARM network trouble after recent mbuf changes From: Michael Tuexen In-Reply-To: <521C4CD9.4050308@freebsd.org> Date: Tue, 27 Aug 2013 09:02:23 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1377550636.1111.156.camel@revolution.hippie.lan> <521BC472.7040804@freebsd.org> <521BD531.4090104@sbcglobal.net> <521C4CD9.4050308@freebsd.org> To: Andre Oppermann 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: Tue, 27 Aug 2013 07:02:15 -0000 On Aug 27, 2013, at 8:53 AM, Andre Oppermann wrote: > On 27.08.2013 00:22, Thomas Skibo wrote: >> On 8/26/13 2:11 PM, Andre Oppermann wrote: >>>=20 >>> Can you try this patch see check if it makes a difference on the = bitfield? >>=20 >> Actually, this works for me. But, I'm worried that somewhere else = something is going to trip over a >> struct pkthdr not being 64-bit aligned. There are several 64-bit = fields in there. >=20 > The problem is the disconnect between the definition of MLEN and MHLEN = and > the effective size/padding of struct mbuf. That's the true bug. >=20 > On LP64 all is fine. On i386 it turns out to be fine too because = doesn't > care. >=20 > MLEN and MHLEN are incorrectly derived. In fact they should be = derived from > stuct mbuf where this padding would be taking into account. However = the way > it is structured right now it that would create a circular dependency. >=20 > Please try the patch below to confirm. If it fixes your problem for = now > I'm going to commit as an immediate fix while searching for a better = long > term stable solution. >=20 > --=20 > Andre >=20 > Index: sys/mbuf.h > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- sys/mbuf.h (revision 254953) > +++ sys/mbuf.h (working copy) > @@ -94,6 +94,9 @@ > int32_t mh_len; /* amount of data in this mbuf = */ > uint32_t mh_type:8, /* type of data in this mbuf */ > mh_flags:24; /* flags; see below */ > +#if defined(__ILP32__) > + uint32_t mh_pad; /* pad to 64 bit alignment */ > +#endif > }; Looks good to me and should fix it. I started a build with this change = for a RPi. I'll report if it fixes the issue if noone else is faster... Best regards Michael >=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 From owner-freebsd-arm@FreeBSD.ORG Tue Aug 27 07:21: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 0835B7F9; Tue, 27 Aug 2013 07:21:47 +0000 (UTC) (envelope-from iz-rpi03@hs-karlsruhe.de) Received: from smtp.hs-karlsruhe.de (smtp.HS-Karlsruhe.DE [193.196.64.25]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id BF929218E; Tue, 27 Aug 2013 07:21:46 +0000 (UTC) Received: from iz-wera01.hs-karlsruhe.de ([193.196.65.46]) by smtp.hs-karlsruhe.de with esmtp (Exim 4.80.1) (envelope-from ) id 1VEDay-004wtS-OQ; Tue, 27 Aug 2013 09:21:44 +0200 X-Mailer: exmh version 2.8.0 04/21/2012 with nmh-1.5 From: Ralf Wenk To: Adrian Chadd Subject: Re: Pretty good RPi version? In-reply-to: References: <5218FBE2.2000907@m5p.com> <20130825.195532.59669686.shigeru@os-hackers.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 27 Aug 2013 08:50:39 +0200 Message-Id: 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, 27 Aug 2013 07:21:47 -0000 On 2013-Aug-25 05:07:37 -0700, Adrian Chadd wrote: >All - if it's unstable, please complain loudly on -arm and -current and >file PRs. If you have the time, please help figure out which commit(s) >broke things. There is a bug preventing mount_smbfs to work on arm. Details and a patch are in the bug report http://www.freebsd.org/cgi/query-pr.cgi?pr=180438 I am sorry, it only got to -fs. After learning that ist is caused by assumption when doing casting to a different type I am a little bit worried if this could be the cause of other bugs/problems, e.g. the newfs problem on arm pr=177538, as well. Ralf From owner-freebsd-arm@FreeBSD.ORG Tue Aug 27 09:28: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 B35EE729; Tue, 27 Aug 2013 09:28:24 +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 954DF29E9; Tue, 27 Aug 2013 09:28:24 +0000 (UTC) Received: from bender (global-1-18.nat.csx.cam.ac.uk [131.111.184.18]) by nibbler.fubar.geek.nz (Postfix) with ESMTPSA id 612D65DFF7; Tue, 27 Aug 2013 09:28:17 +0000 (UTC) Date: Tue, 27 Aug 2013 10:28:10 +0100 From: Andrew Turner To: Andre Oppermann Subject: Re: ARM network trouble after recent mbuf changes Message-ID: <20130827102810.37e2dfc7@bender> In-Reply-To: <521C4CD9.4050308@freebsd.org> References: <1377550636.1111.156.camel@revolution.hippie.lan> <521BC472.7040804@freebsd.org> <521BD531.4090104@sbcglobal.net> <521C4CD9.4050308@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Aug 2013 09:28:24 -0000 On Tue, 27 Aug 2013 08:53:13 +0200 Andre Oppermann wrote: > Please try the patch below to confirm. If it fixes your problem for > now I'm going to commit as an immediate fix while searching for a > better long term stable solution. > I tried this with a CTASSERT to check if struct m_hdr is the correct length. In this test the size is incorrect. It appears __ILP32__ is not defined on ARM. I have tested a fix suggested by Hans Petter Selasky where we mark m_hdr with __aligned(8). With this change I can netboot a PandaBoard. Andrew From owner-freebsd-arm@FreeBSD.ORG Tue Aug 27 09:36:41 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 25B3E8C0 for ; Tue, 27 Aug 2013 09:36:41 +0000 (UTC) (envelope-from fabiodive@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 AD5892A6B for ; Tue, 27 Aug 2013 09:36:40 +0000 (UTC) Received: by mail-ee0-f47.google.com with SMTP id d49so2098474eek.20 for ; Tue, 27 Aug 2013 02:36:38 -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=9e9kj/wpAMcO09bTRhYnK8mqEbOSbrHucNt8lZ7/DpM=; b=VbAO6mjfP5liOsuVzrIt3atD0ZKsigr8y7HPnykmKGa6DH78N34deOGr4TPr7mBYIY h2BRi/pIPCOJekyDdS/Kt6dl0ezGttPn8R1U6YRjSfpeFOByxKK5M1KC7gpZZBgLEoB7 2vg+t4RF80EkAQ0rtWQfP7eV3NuIsTsF/S0X3Cn/0634ysS6REr7KHoGxXh2E9GsEPsr /Y+TbV9hmZDKGaeG2HQfvGizFibSgCj3W9RBNluyelutzfSsYZPCOvdtHtctG34F2KvH EGrCpuD4hu81aD8U86meoTaO7EqG2lz+fsG8U8R96l6afLFtoeegIYn0RNNGe1mJlIGw vBQQ== X-Received: by 10.15.35.1 with SMTP id f1mr746731eev.79.1377596198904; Tue, 27 Aug 2013 02:36:38 -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 f49sm27712361eec.7.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 27 Aug 2013 02:36:37 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Subject: Re: HEADS UP: Superpages support for ARMv6/v7 From: fabiodive In-Reply-To: <521BA6F6.3010308@semihalf.com> Date: Tue, 27 Aug 2013 10:36:34 +0100 Content-Transfer-Encoding: 7bit Message-Id: <0093E5B7-EC77-40AB-8AD4-0778E42993A6@gmail.com> References: <521BA6F6.3010308@semihalf.com> To: Zbyszek Bodek X-Mailer: Apple Mail (2.1508) Cc: freebsd-arm@FreeBSD.org, Alan Cox 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, 27 Aug 2013 09:36:41 -0000 Hello, I am going to do some tests on my beagle bone black here, please could you give me an hint about enabling the feature into the kernel? Which directive should I use? thank you f. On Aug 26, 2013, at 8:05 PM, Zbyszek Bodek wrote: > Hello Everyone. > > I'm happy to announce that Superpages support for ARM has just been > integrated to the FreeBSD HEAD: > http://svnweb.freebsd.org/changeset/base/254918 > > This project was sponsored by The FreeBSD Foundation and Semihalf. > It was developed with great support of Alan Cox (alc) who was also the > technical reviewer of the code. Thank you very much Alan for all your help! > I would also like to thank Grzegorz Bernacki (gber) and Rafal Jaworowski > (raj) for mentoring and help with the code integration and all the > people involved in testing of the patches and review. > > The code was tested on a quad-core, ARMv7, Marvell Armada XP SoC in SMP > environment. > > Superpages is a feature that can increase TLB coverage and allow for > efficient use of page table entries. Current implementation for ARM > supports two page sizes: 4KB small pages (used as base pages) and 1MB > sections (used as superpages). > Superpages are created either directly by 1MB section insertion or as a > result of promotion of 256 4KB pages. In both cases superpages creation > and utilization depends on *sp_enabled* sysctl variable. > > By default, superpages support is disabled. > In order to use this functionality one needs to set > *vm.pmap.sp_enabled* tunable to non-zero value. This can be done either > in loader.conf or by modifying *sp_enabled* variable in > sys/arm/arm/pmap-v6.c . Statistics regarding superpages usage are > available through: sysctl vm.pmap.section > > All ARMv6/v7-based platforms can take advantage from superpages, so > please enable this feature on your ARM kernels. > We will appreciate all your feedback regarding performance impact and > general system behavior. > > Performance improvement should be visible in all tasks where intensive > memory utilization is involved. GUPS (Giga Updates Per Second) benchmark > can be used to show the difference in memory utilization efficiency with > superpages enabled and disabled. GUPS src can be downloaded from here: > http://people.freebsd.org/~raj/patches/arm/superpages/GUPS.tar.gz > > Exemplary GUPS results: > -------------------------------------------------------------------- > *superpages enabled* > vm.pmap.section.promotions: 1024 > vm.pmap.section.p_failures: 58 > vm.pmap.section.mappings: 0 > vm.pmap.section.demotions: 0 > > # ./gups > Main table size = 2^27 = 134217728 words > Number of updates = 536870912 > CPU time used = 97.085938 seconds > Real time used = 97.082504 seconds > 0.005530048 Billion(10^9) Updates per second [GUP/s] > > vm.pmap.section.promotions: 2048 > vm.pmap.section.p_failures: 58 > vm.pmap.section.mappings: 0 > vm.pmap.section.demotions: 0 > > * superpages disabled * > Main table size = 2^27 = 134217728 words > Number of updates = 536870912 > CPU time used = 145.679688 seconds > Real time used = 145.680798 seconds > 0.003685255 Billion(10^9) Updates per second [GUP/s] > -------------------------------------------------------------------- > > *Self host buildworld* > World build time on Armada XP has shortened from 6h 36min to > 5h 14min with superpages enabled. > > *Stress tests* > stress --cpu 4 --io 4 --vm 2 --vm-bytes 800M > Survived long time runs, large superpages creation ratio has been observed. > > *Swapping* > No problems with swapping or system running under heavy load with > shortage of memory have been observed. > > > Please feel free to send your results. > > Best regards > Zbigniew Bodek > _______________________________________________ > 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 Aug 27 09:37:54 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 E24B3909; Tue, 27 Aug 2013 09:37:54 +0000 (UTC) (envelope-from tuexen@freebsd.org) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 7598E2A74; Tue, 27 Aug 2013 09:37:54 +0000 (UTC) Received: from [192.168.1.200] (p508F3337.dip0.t-ipconnect.de [80.143.51.55]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 94E661C0C0692; Tue, 27 Aug 2013 11:37:51 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Subject: Re: ARM network trouble after recent mbuf changes From: Michael Tuexen In-Reply-To: <521C4CD9.4050308@freebsd.org> Date: Tue, 27 Aug 2013 11:38:00 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <0E0536B2-2B7F-4EED-9EFD-4B9E2C2D729A@freebsd.org> References: <1377550636.1111.156.camel@revolution.hippie.lan> <521BC472.7040804@freebsd.org> <521BD531.4090104@sbcglobal.net> <521C4CD9.4050308@freebsd.org> To: Andre Oppermann 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: Tue, 27 Aug 2013 09:37:55 -0000 On Aug 27, 2013, at 8:53 AM, Andre Oppermann wrote: > On 27.08.2013 00:22, Thomas Skibo wrote: >> On 8/26/13 2:11 PM, Andre Oppermann wrote: >>>=20 >>> Can you try this patch see check if it makes a difference on the = bitfield? >>=20 >> Actually, this works for me. But, I'm worried that somewhere else = something is going to trip over a >> struct pkthdr not being 64-bit aligned. There are several 64-bit = fields in there. >=20 > The problem is the disconnect between the definition of MLEN and MHLEN = and > the effective size/padding of struct mbuf. That's the true bug. >=20 > On LP64 all is fine. On i386 it turns out to be fine too because = doesn't > care. >=20 > MLEN and MHLEN are incorrectly derived. In fact they should be = derived from > stuct mbuf where this padding would be taking into account. However = the way > it is structured right now it that would create a circular dependency. >=20 > Please try the patch below to confirm. If it fixes your problem for = now > I'm going to commit as an immediate fix while searching for a better = long > term stable solution. >=20 > --=20 > Andre >=20 > Index: sys/mbuf.h > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- sys/mbuf.h (revision 254953) > +++ sys/mbuf.h (working copy) > @@ -94,6 +94,9 @@ > int32_t mh_len; /* amount of data in this mbuf = */ > uint32_t mh_type:8, /* type of data in this mbuf */ > mh_flags:24; /* flags; see below */ > +#if defined(__ILP32__) > + uint32_t mh_pad; /* pad to 64 bit alignment */ > +#endif > }; OK. It doesn't work. The reason is, that __ILP32__ is not defined... At lease I don't see it anywhere in the BSD stack. So I'm currently = rebuilding with #if !defined(__LP64__) instead. I'll let you know... Best regards Michael >=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 From owner-freebsd-arm@FreeBSD.ORG Tue Aug 27 09:45:19 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 D76BC9DF for ; Tue, 27 Aug 2013 09:45:19 +0000 (UTC) (envelope-from fabiodive@gmail.com) Received: from mail-ee0-x229.google.com (mail-ee0-x229.google.com [IPv6:2a00:1450:4013:c00::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 58B212AE4 for ; Tue, 27 Aug 2013 09:45:19 +0000 (UTC) Received: by mail-ee0-f41.google.com with SMTP id d17so2154933eek.14 for ; Tue, 27 Aug 2013 02:45:17 -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=8qn2azYwzIX0rPQ28D7ClWRM1K02GLnXpqNqTOgLpGc=; b=G8OPZkQ5n4Ba5E4gi+6A6ngdaj579y+2935wu2618GBKICFVI+uqkqJgLYlQUO/UVI BzhNuWWpWNcE574O5VUTTIb2l5Y8V4az5JvVzaaxLmobtjDJe8KifRlSOiroDGrneHSG RTQm30D8t3Zx3tcFUpVxn7nhJoYVc+CeJx6aObyCQfEAf6E4FWmIBN87BvFa6qMEIJrJ MZ5NAz4fBxDhbNZrwAwKykH1mXba5lFwSP6P25cD/Y2qhN+AmEtmPAY5CDgOSwfASlLj Q8hjtTqGKB0enxTKQafuN87oNSLQb3MYseyi+v4WnwOGYGqQaLI5s773IRaZYI8d+slQ tEqg== X-Received: by 10.14.241.74 with SMTP id f50mr33518733eer.29.1377596717528; Tue, 27 Aug 2013 02:45:17 -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 j7sm27745827eeo.15.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 27 Aug 2013 02:45:17 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Subject: Re: HEADS UP: Superpages support for ARMv6/v7 From: fabiodive In-Reply-To: <521C74A3.4050207@semihalf.com> Date: Tue, 27 Aug 2013 10:45:14 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <3635F96E-6C83-4310-AE6B-DE2F2EA09C4C@gmail.com> References: <521BA6F6.3010308@semihalf.com> <0093E5B7-EC77-40AB-8AD4-0778E42993A6@gmail.com> <521C74A3.4050207@semihalf.com> To: Zbyszek Bodek 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, 27 Aug 2013 09:45:19 -0000 OK, that's fine, should be fine also having some configuration "option" into the kernel configuration file=85 thank you again f. On Aug 27, 2013, at 10:42 AM, Zbyszek Bodek wrote: > On 27.08.2013 11:36, fabiodive wrote: >> Hello, >> I am going to do some tests on my beagle bone black here, >> please could you give me an hint about enabling the feature >> into the kernel? Which directive should I use? >> thank you >> f. >>=20 >=20 > Hello. >=20 > If you are not using loader then open: > sys/arm/arm/pmap-v6.c > and set "sp_enabled =3D 0;" -> "sp_enabled =3D 1;" > recompile. >=20 > OR if using loader then set: > vm.pmap.sp_enabled=3D1 in loader.conf >=20 > Both methods are sufficient. >=20 > Best regards > Zbigniew Bodek >=20 >=20 >> On Aug 26, 2013, at 8:05 PM, Zbyszek Bodek wrote: >>=20 >>> Hello Everyone. >>>=20 >>> I'm happy to announce that Superpages support for ARM has just been >>> integrated to the FreeBSD HEAD: >>> http://svnweb.freebsd.org/changeset/base/254918 >>>=20 >>> This project was sponsored by The FreeBSD Foundation and Semihalf. >>> It was developed with great support of Alan Cox (alc) who was also = the >>> technical reviewer of the code. Thank you very much Alan for all = your help! >>> I would also like to thank Grzegorz Bernacki (gber) and Rafal = Jaworowski >>> (raj) for mentoring and help with the code integration and all the >>> people involved in testing of the patches and review. >>>=20 >>> The code was tested on a quad-core, ARMv7, Marvell Armada XP SoC in = SMP >>> environment. >>>=20 >>> Superpages is a feature that can increase TLB coverage and allow for >>> efficient use of page table entries. Current implementation for ARM >>> supports two page sizes: 4KB small pages (used as base pages) and = 1MB >>> sections (used as superpages). >>> Superpages are created either directly by 1MB section insertion or = as a >>> result of promotion of 256 4KB pages. In both cases superpages = creation >>> and utilization depends on *sp_enabled* sysctl variable. >>>=20 >>> By default, superpages support is disabled. >>> In order to use this functionality one needs to set >>> *vm.pmap.sp_enabled* tunable to non-zero value. This can be done = either >>> in loader.conf or by modifying *sp_enabled* variable in >>> sys/arm/arm/pmap-v6.c . Statistics regarding superpages usage are >>> available through: sysctl vm.pmap.section >>>=20 >>> All ARMv6/v7-based platforms can take advantage from superpages, so >>> please enable this feature on your ARM kernels. >>> We will appreciate all your feedback regarding performance impact = and >>> general system behavior. >>>=20 >>> Performance improvement should be visible in all tasks where = intensive >>> memory utilization is involved. GUPS (Giga Updates Per Second) = benchmark >>> can be used to show the difference in memory utilization efficiency = with >>> superpages enabled and disabled. GUPS src can be downloaded from = here: >>> http://people.freebsd.org/~raj/patches/arm/superpages/GUPS.tar.gz >>>=20 >>> Exemplary GUPS results: >>> -------------------------------------------------------------------- >>> *superpages enabled* >>> vm.pmap.section.promotions: 1024 >>> vm.pmap.section.p_failures: 58 >>> vm.pmap.section.mappings: 0 >>> vm.pmap.section.demotions: 0 >>>=20 >>> # ./gups >>> Main table size =3D 2^27 =3D 134217728 words >>> Number of updates =3D 536870912 >>> CPU time used =3D 97.085938 seconds >>> Real time used =3D 97.082504 seconds >>> 0.005530048 Billion(10^9) Updates per second [GUP/s] >>>=20 >>> vm.pmap.section.promotions: 2048 >>> vm.pmap.section.p_failures: 58 >>> vm.pmap.section.mappings: 0 >>> vm.pmap.section.demotions: 0 >>>=20 >>> * superpages disabled * >>> Main table size =3D 2^27 =3D 134217728 words >>> Number of updates =3D 536870912 >>> CPU time used =3D 145.679688 seconds >>> Real time used =3D 145.680798 seconds >>> 0.003685255 Billion(10^9) Updates per second [GUP/s] >>> -------------------------------------------------------------------- >>>=20 >>> *Self host buildworld* >>> World build time on Armada XP has shortened from 6h 36min to >>> 5h 14min with superpages enabled. >>>=20 >>> *Stress tests* >>> stress --cpu 4 --io 4 --vm 2 --vm-bytes 800M >>> Survived long time runs, large superpages creation ratio has been = observed. >>>=20 >>> *Swapping* >>> No problems with swapping or system running under heavy load with >>> shortage of memory have been observed. >>>=20 >>>=20 >>> Please feel free to send your results. >>>=20 >>> Best regards >>> Zbigniew Bodek >>> _______________________________________________ >>> 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 Tue Aug 27 09:49:36 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 1A426A5F for ; Tue, 27 Aug 2013 09:49:36 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 7F9D62B05 for ; Tue, 27 Aug 2013 09:49:35 +0000 (UTC) Received: (qmail 12878 invoked from network); 27 Aug 2013 10:31:37 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 27 Aug 2013 10:31:37 -0000 Message-ID: <521C762A.2080109@freebsd.org> Date: Tue, 27 Aug 2013 11:49:30 +0200 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Andrew Turner Subject: Re: ARM network trouble after recent mbuf changes References: <1377550636.1111.156.camel@revolution.hippie.lan> <521BC472.7040804@freebsd.org> <521BD531.4090104@sbcglobal.net> <521C4CD9.4050308@freebsd.org> <20130827102810.37e2dfc7@bender> In-Reply-To: <20130827102810.37e2dfc7@bender> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Aug 2013 09:49:36 -0000 On 27.08.2013 11:28, Andrew Turner wrote: > On Tue, 27 Aug 2013 08:53:13 +0200 > Andre Oppermann wrote: >> Please try the patch below to confirm. If it fixes your problem for >> now I'm going to commit as an immediate fix while searching for a >> better long term stable solution. >> > > I tried this with a CTASSERT to check if struct m_hdr is the correct > length. In this test the size is incorrect. It appears __ILP32__ is not > defined on ARM. > > I have tested a fix suggested by Hans Petter Selasky where we mark > m_hdr with __aligned(8). With this change I can netboot a PandaBoard. There is no guarantee with __aligned(8) that the padding is included in sizeof(struct m_hdr). It only guarantees that the start of m_hdr is aligned on a 8 byte multiple. In your case it appears that the padding is included. I'm not certain that we can rely on it with both gcc and clang (or some other compiler). -- Andre From owner-freebsd-arm@FreeBSD.ORG Tue Aug 27 10:08: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 A3F95C7D for ; Tue, 27 Aug 2013 10:08:25 +0000 (UTC) (envelope-from zbb@semihalf.com) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 1F8FD2BF3 for ; Tue, 27 Aug 2013 10:08:24 +0000 (UTC) Received: by mail-bk0-f44.google.com with SMTP id mz10so1511979bkb.17 for ; Tue, 27 Aug 2013 03:08:17 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=K49796RWZfSrhO/b/01CXGbemiWS5VyyrvBXkZQ+X58=; b=f9E5ElQvarvqo/8ZxBDBwlVLMqXLnUQd/Q97q6u1yyz5X+kz0G7gk3uvgZExUOuFWC 0XbCbvH1B55+b4N4RQzkXuzoZYAT1njGIRyHuVtjlpLOPPA7WmgvuCrv0sWluOwgxSja XRlvXTV5mM2yB4FxKja1/FoNZ0HMqCXmHXGtodm0zTfBkVUka5z/BSGi0yZzC0y8ws7r nM+b2/0SNTe8R9ZTjsaLD+pOTOPfXlE++Dim52zwZXmJxHZoi6CSgO8eUmOuVSCIdSBd wFoiUvcto6n3NTTqIGUh5/piYYy5js/ErJ3mTV1zwDeNDBSZ6QP+eKrcoL2IiWNYVMCR 23FQ== X-Gm-Message-State: ALoCoQmam73z+SeqDwFZ42VLEWFn8kZg+8i5rID1HrqPLZ5+SP3bhlHB2wTxX5uIvguevT6FGvsa X-Received: by 10.205.36.70 with SMTP id sz6mr13603342bkb.12.1377597744464; Tue, 27 Aug 2013 03:02:24 -0700 (PDT) Received: from [10.0.2.117] (cardhu.semihalf.com. [213.17.239.108]) by mx.google.com with ESMTPSA id zl3sm4099976bkb.4.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 27 Aug 2013 03:02:23 -0700 (PDT) Message-ID: <521C792D.1030704@semihalf.com> Date: Tue, 27 Aug 2013 12:02:21 +0200 From: Zbyszek Bodek Organization: Semihalf User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130803 Thunderbird/17.0.8 MIME-Version: 1.0 To: fabiodive Subject: Re: HEADS UP: Superpages support for ARMv6/v7 References: <521BA6F6.3010308@semihalf.com> <0093E5B7-EC77-40AB-8AD4-0778E42993A6@gmail.com> <521C74A3.4050207@semihalf.com> <3635F96E-6C83-4310-AE6B-DE2F2EA09C4C@gmail.com> In-Reply-To: <3635F96E-6C83-4310-AE6B-DE2F2EA09C4C@gmail.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit 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, 27 Aug 2013 10:08:25 -0000 On 27.08.2013 11:45, fabiodive wrote: > OK, that's fine, should be fine also having some configuration > "option" into the kernel configuration file… > thank you again > f. Hello again. Well, in general on i386/amd64 this feature is enabled by default. It would be reasonable to enable SP by default on ARM too after longer tests and evaluation on various ARM-based chips. But you are right, it would be convenient to enable this in kernel configuration especially on ARM. I will discuss this with Developers. Best regards > > > On Aug 27, 2013, at 10:42 AM, Zbyszek Bodek wrote: > >> On 27.08.2013 11:36, fabiodive wrote: >>> Hello, >>> I am going to do some tests on my beagle bone black here, >>> please could you give me an hint about enabling the feature >>> into the kernel? Which directive should I use? >>> thank you >>> f. >>> >> >> Hello. >> >> If you are not using loader then open: >> sys/arm/arm/pmap-v6.c >> and set "sp_enabled = 0;" -> "sp_enabled = 1;" >> recompile. >> >> OR if using loader then set: >> vm.pmap.sp_enabled=1 in loader.conf >> >> Both methods are sufficient. >> >> Best regards >> Zbigniew Bodek >> >> >>> On Aug 26, 2013, at 8:05 PM, Zbyszek Bodek wrote: >>> >>>> Hello Everyone. >>>> >>>> I'm happy to announce that Superpages support for ARM has just been >>>> integrated to the FreeBSD HEAD: >>>> http://svnweb.freebsd.org/changeset/base/254918 >>>> >>>> This project was sponsored by The FreeBSD Foundation and Semihalf. >>>> It was developed with great support of Alan Cox (alc) who was also the >>>> technical reviewer of the code. Thank you very much Alan for all your help! >>>> I would also like to thank Grzegorz Bernacki (gber) and Rafal Jaworowski >>>> (raj) for mentoring and help with the code integration and all the >>>> people involved in testing of the patches and review. >>>> >>>> The code was tested on a quad-core, ARMv7, Marvell Armada XP SoC in SMP >>>> environment. >>>> >>>> Superpages is a feature that can increase TLB coverage and allow for >>>> efficient use of page table entries. Current implementation for ARM >>>> supports two page sizes: 4KB small pages (used as base pages) and 1MB >>>> sections (used as superpages). >>>> Superpages are created either directly by 1MB section insertion or as a >>>> result of promotion of 256 4KB pages. In both cases superpages creation >>>> and utilization depends on *sp_enabled* sysctl variable. >>>> >>>> By default, superpages support is disabled. >>>> In order to use this functionality one needs to set >>>> *vm.pmap.sp_enabled* tunable to non-zero value. This can be done either >>>> in loader.conf or by modifying *sp_enabled* variable in >>>> sys/arm/arm/pmap-v6.c . Statistics regarding superpages usage are >>>> available through: sysctl vm.pmap.section >>>> >>>> All ARMv6/v7-based platforms can take advantage from superpages, so >>>> please enable this feature on your ARM kernels. >>>> We will appreciate all your feedback regarding performance impact and >>>> general system behavior. >>>> >>>> Performance improvement should be visible in all tasks where intensive >>>> memory utilization is involved. GUPS (Giga Updates Per Second) benchmark >>>> can be used to show the difference in memory utilization efficiency with >>>> superpages enabled and disabled. GUPS src can be downloaded from here: >>>> http://people.freebsd.org/~raj/patches/arm/superpages/GUPS.tar.gz >>>> >>>> Exemplary GUPS results: >>>> -------------------------------------------------------------------- >>>> *superpages enabled* >>>> vm.pmap.section.promotions: 1024 >>>> vm.pmap.section.p_failures: 58 >>>> vm.pmap.section.mappings: 0 >>>> vm.pmap.section.demotions: 0 >>>> >>>> # ./gups >>>> Main table size = 2^27 = 134217728 words >>>> Number of updates = 536870912 >>>> CPU time used = 97.085938 seconds >>>> Real time used = 97.082504 seconds >>>> 0.005530048 Billion(10^9) Updates per second [GUP/s] >>>> >>>> vm.pmap.section.promotions: 2048 >>>> vm.pmap.section.p_failures: 58 >>>> vm.pmap.section.mappings: 0 >>>> vm.pmap.section.demotions: 0 >>>> >>>> * superpages disabled * >>>> Main table size = 2^27 = 134217728 words >>>> Number of updates = 536870912 >>>> CPU time used = 145.679688 seconds >>>> Real time used = 145.680798 seconds >>>> 0.003685255 Billion(10^9) Updates per second [GUP/s] >>>> -------------------------------------------------------------------- >>>> >>>> *Self host buildworld* >>>> World build time on Armada XP has shortened from 6h 36min to >>>> 5h 14min with superpages enabled. >>>> >>>> *Stress tests* >>>> stress --cpu 4 --io 4 --vm 2 --vm-bytes 800M >>>> Survived long time runs, large superpages creation ratio has been observed. >>>> >>>> *Swapping* >>>> No problems with swapping or system running under heavy load with >>>> shortage of memory have been observed. >>>> >>>> >>>> Please feel free to send your results. >>>> >>>> Best regards >>>> Zbigniew Bodek >>>> _______________________________________________ >>>> 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 Aug 27 11:05: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 3665C6E1 for ; Tue, 27 Aug 2013 11:05:41 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 7F6802EF9 for ; Tue, 27 Aug 2013 11:05:40 +0000 (UTC) Received: (qmail 13197 invoked from network); 27 Aug 2013 11:47:41 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 27 Aug 2013 11:47:41 -0000 Message-ID: <521C87FF.8010100@freebsd.org> Date: Tue, 27 Aug 2013 13:05:35 +0200 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Michael Tuexen Subject: Re: ARM network trouble after recent mbuf changes References: <1377550636.1111.156.camel@revolution.hippie.lan> <521BC472.7040804@freebsd.org> <521BD531.4090104@sbcglobal.net> <521C4CD9.4050308@freebsd.org> <0E0536B2-2B7F-4EED-9EFD-4B9E2C2D729A@freebsd.org> In-Reply-To: <0E0536B2-2B7F-4EED-9EFD-4B9E2C2D729A@freebsd.org> Content-Type: multipart/mixed; boundary="------------070207030006050305010600" Cc: freebsd-arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Aug 2013 11:05:41 -0000 This is a multi-part message in MIME format. --------------070207030006050305010600 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 27.08.2013 11:38, Michael Tuexen wrote: > On Aug 27, 2013, at 8:53 AM, Andre Oppermann wrote: > >> On 27.08.2013 00:22, Thomas Skibo wrote: >>> On 8/26/13 2:11 PM, Andre Oppermann wrote: >>>> >>>> Can you try this patch see check if it makes a difference on the bitfield? >>> >>> Actually, this works for me. But, I'm worried that somewhere else something is going to trip over a >>> struct pkthdr not being 64-bit aligned. There are several 64-bit fields in there. >> >> The problem is the disconnect between the definition of MLEN and MHLEN and >> the effective size/padding of struct mbuf. That's the true bug. >> >> On LP64 all is fine. On i386 it turns out to be fine too because doesn't >> care. >> >> MLEN and MHLEN are incorrectly derived. In fact they should be derived from >> stuct mbuf where this padding would be taking into account. However the way >> it is structured right now it that would create a circular dependency. >> >> Please try the patch below to confirm. If it fixes your problem for now >> I'm going to commit as an immediate fix while searching for a better long >> term stable solution. >> >> -- >> Andre >> >> Index: sys/mbuf.h >> =================================================================== >> --- sys/mbuf.h (revision 254953) >> +++ sys/mbuf.h (working copy) >> @@ -94,6 +94,9 @@ >> int32_t mh_len; /* amount of data in this mbuf */ >> uint32_t mh_type:8, /* type of data in this mbuf */ >> mh_flags:24; /* flags; see below */ >> +#if defined(__ILP32__) >> + uint32_t mh_pad; /* pad to 64 bit alignment */ >> +#endif >> }; > > OK. It doesn't work. The reason is, that __ILP32__ is not defined... At > lease I don't see it anywhere in the BSD stack. So I'm currently rebuilding > with #if !defined(__LP64__) instead. I'll let you know... Thanks. I've changed the test accordingly. While doing the CTASSERTs to prevent such an incident in the future I stumbled across a bit of evil name space pollution in mbuf.h. It is impossible to take sizeof(struct m_ext) because "m_ext" is redefined to point into struct mbuf. In addition to the alignment fix I've solved the namespace issues with m_ext and the stupidly named struct pkthdr as well and properly prefixed them. The fallout from LINT was zero (as it should be). http://people.freebsd.org/~andre/m_hdr-alignment-20130827.diff Please test. -- Andre --------------070207030006050305010600 Content-Type: text/plain; charset=windows-1252; name="m_hdr-alignment-20130827.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="m_hdr-alignment-20130827.diff" Index: sys/mbuf.h =================================================================== --- sys/mbuf.h (revision 254953) +++ sys/mbuf.h (working copy) @@ -53,12 +53,16 @@ * externally and attach it to the mbuf in a way similar to that of mbuf * clusters. * + * NB: These calculation do not take actual compiler-induced alignment and + * padding inside the complete struct mbuf into account. Appropriate attention + * is required when changing members of struct mbuf. + * * MLEN is data length in a normal mbuf. * MHLEN is data length in an mbuf with pktheader. * MINCLSIZE is a smallest amount of data that should be put into cluster. */ -#define MLEN ((int)(MSIZE - sizeof(struct m_hdr))) -#define MHLEN ((int)(MLEN - sizeof(struct pkthdr))) +#define MLEN ((int)(MSIZE - sizeof(struct mh_hdr))) +#define MHLEN ((int)(MLEN - sizeof(struct mh_pkthdr))) #define MINCLSIZE (MHLEN + 1) #ifdef _KERNEL @@ -67,7 +71,7 @@ * type: * * mtod(m, t) -- Convert mbuf pointer to data pointer of correct type. - * mtodo(m, o) -- Same as above but with offset 'o' into data. + * mtodo(m, o) -- Same as above but with offset 'o' into data. */ #define mtod(m, t) ((t)((m)->m_data)) #define mtodo(m, o) ((void *)(((m)->m_data) + (o))) @@ -84,10 +88,10 @@ /* * Header present at the beginning of every mbuf. - * Size ILP32: 20 + * Size ILP32: 24 * LP64: 32 */ -struct m_hdr { +struct mh_hdr { struct mbuf *mh_next; /* next buffer in chain */ struct mbuf *mh_nextpkt; /* next chain in queue/record */ caddr_t mh_data; /* location of data */ @@ -94,10 +98,15 @@ int32_t mh_len; /* amount of data in this mbuf */ uint32_t mh_type:8, /* type of data in this mbuf */ mh_flags:24; /* flags; see below */ +#if !defined(__LP64__) + uint32_t mh_pad; /* pad for 64bit alignment */ +#endif }; /* * Packet tag structure (see below for details). + * Size ILP32: 16 + * LP64: 24 */ struct m_tag { SLIST_ENTRY(m_tag) m_tag_link; /* List of packet tags */ @@ -112,7 +121,7 @@ * Size ILP32: 48 * LP64: 56 */ -struct pkthdr { +struct mh_pkthdr { struct ifnet *rcvif; /* rcv interface */ SLIST_HEAD(packet_tags, m_tag) tags; /* list of packet tags */ int32_t len; /* total packet length */ @@ -159,7 +168,7 @@ * Size ILP32: 28 * LP64: 48 */ -struct m_ext { +struct mh_ext { volatile u_int *ref_cnt; /* pointer to ref count info */ caddr_t ext_buf; /* start of buffer */ uint32_t ext_size; /* size of buffer, for ext_free */ @@ -176,18 +185,18 @@ * purposes. */ struct mbuf { - struct m_hdr m_hdr; + struct mh_hdr m_hdr; union { struct { - struct pkthdr MH_pkthdr; /* M_PKTHDR set */ + struct mh_pkthdr MH_pkthdr; /* M_PKTHDR set */ union { - struct m_ext MH_ext; /* M_EXT set */ + struct mh_ext MH_ext; /* M_EXT set */ char MH_databuf[MHLEN]; } MH_dat; } MH; char M_databuf[MLEN]; /* !M_PKTHDR, !M_EXT */ } M_dat; -}; +} __aligned(sizeof(uint64_t)); #define m_next m_hdr.mh_next #define m_len m_hdr.mh_len #define m_data m_hdr.mh_data Index: kern/uipc_mbuf.c =================================================================== --- kern/uipc_mbuf.c (revision 254953) +++ kern/uipc_mbuf.c (working copy) @@ -85,6 +85,17 @@ #endif /* + * Ensure the correct size of various mbuf parameters. It could be off due + * to compiler-induced padding and alignment artifacts. + */ +CTASSERT(sizeof(struct mbuf) == MSIZE); +CTASSERT(sizeof(((struct mbuf *)0)->m_hdr) == sizeof(struct mh_hdr)); +CTASSERT(sizeof(((struct mbuf *)0)->m_pkthdr) == sizeof(struct mh_pkthdr)); +CTASSERT(sizeof(((struct mbuf *)0)->m_ext) == sizeof(struct mh_ext)); +CTASSERT(sizeof(((struct mbuf *)0)->m_dat) == MLEN); +CTASSERT(sizeof(((struct mbuf *)0)->m_pktdat) == MHLEN); + +/* * m_get2() allocates minimum mbuf that would fit "size" argument. */ struct mbuf * @@ -389,7 +400,7 @@ if (m->m_flags & M_PKTHDR) { m_tag_delete_chain(m, NULL); m->m_flags &= ~M_PKTHDR; - bzero(&m->m_pkthdr, sizeof(struct pkthdr)); + bzero(&m->m_pkthdr, sizeof(struct mh_pkthdr)); } if (m != m0 && m->m_nextpkt != NULL) { KASSERT(m->m_nextpkt == NULL, --------------070207030006050305010600-- From owner-freebsd-arm@FreeBSD.ORG Tue Aug 27 11:11: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 7646B7B8; Tue, 27 Aug 2013 11:11:56 +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 27A8B2F60; Tue, 27 Aug 2013 11:11:56 +0000 (UTC) Received: from wonderland.m5p.com (localhost [IPv6:::1]) by mailhost.m5p.com (8.14.5/8.14.5) with ESMTP id r7RBBlp8097269; Tue, 27 Aug 2013 07:11:52 -0400 (EDT) (envelope-from george+freebsd@m5p.com) Message-ID: <521C8973.4080504@m5p.com> Date: Tue, 27 Aug 2013 07:11:47 -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: Hans Petter Selasky Subject: Re: ulpt can't attach Lexmark E120 References: <5105527F.3010708@m5p.com> <201301271915.47712.hselasky@c2i.net> <510570C1.1060607@m5p.com> <201301272007.30682.hselasky@c2i.net> <5105AB16.2000607@m5p.com> <5215F4DF.6000305@m5p.com> <5215F743.8060403@bitfrost.no> <5216ACE5.7000500@m5p.com> <5216FE9F.2030608@bitfrost.no> <52174378.2020101@m5p.com> <521801E5.9000309@m5p.com> <52184F59.5080100@bitfrost.no> <5218F993.9050504@m5p.com> <5219C3FF.1070509@bitfrost.no> <521A9155.5010102@m5p.com> In-Reply-To: <521A9155.5010102@m5p.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.73 on 10.100.0.3 X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.7 (mailhost.m5p.com [IPv6:::1]); Tue, 27 Aug 2013 07:11:52 -0400 (EDT) Cc: freebsd-arm@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: Tue, 27 Aug 2013 11:11:56 -0000 On 08/25/13 19:20, George Mitchell wrote: > On 08/25/13 04:44, Hans Petter Selasky wrote: >> On 08/24/13 20:21, George Mitchell wrote: >>> >>> Setting hw.usb.dwc_otg.debug to any value greater than 0 generates an >>> unending stream of debug output and effectively locks up the chip >>> scrolling the output on the display. Perhaps there are some specific >>> debug messages I could put in ... -- George >> >> Hi, >> >> Can you try this patch: >> >> http://svnweb.freebsd.org/changeset/base/254828 >> >> --HPS >> _______________________________________________ >> [...] > > I started trying to do too many things at once, and as a result it's > going to take me a little while to try this patch out. My apologies! > -- George > Now that I have put my RPi build environment back together, I hope to try your patch tonight. Sorry for the delay! -- George From owner-freebsd-arm@FreeBSD.ORG Tue Aug 27 11:31:47 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id EDAA2BD3 for ; Tue, 27 Aug 2013 11:31:47 +0000 (UTC) (envelope-from zbb@semihalf.com) Received: from mail-bk0-f54.google.com (mail-bk0-f54.google.com [209.85.214.54]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 7CA3D209B for ; Tue, 27 Aug 2013 11:31:47 +0000 (UTC) Received: by mail-bk0-f54.google.com with SMTP id mz12so1611552bkb.13 for ; Tue, 27 Aug 2013 04:31:40 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=hp3r92KMT6kxrMwPEWf/VC+UD4qixIbVAWoIzlTSDTk=; b=MObJY8kLadXw+5o3DIHgStCbDIUCiBiRQpGm8lrpROzze2+0jZHbU+nc7Byu0AhQJ9 8459GhsjkZLuCbf30/C8UCcB6lUb8u6yk+myKX9ffj3eVGckYsjBypjdjbY1ExJ/uE4I oSqwnHGLdpbI/4nmCz4oQjsaZqXuX04lFfL892MtKi1xHypNDSx7JV764KdbtTI0MRpR XRJMfPxirdue4O8IZu2Y84AvdI0R0DJlpwVNJR1oKAZLrwetCHuwU8e3G0CG1CRR9jE+ VrlERG+TYIWbcVkr1hLj9/aLgw3JvR5xkYO6r1vk4aezZXXNv0gOr8pjuMdZooa5Uyb/ xNYw== X-Gm-Message-State: ALoCoQlADpF6Hbj1Bc1cwql1l1ZTV9bmGD2B66BS1Hsaaew5B5qS/IMKvIK+MVCFV05NsKjk9JEc X-Received: by 10.205.33.207 with SMTP id sp15mr13203013bkb.2.1377596581876; Tue, 27 Aug 2013 02:43:01 -0700 (PDT) Received: from [10.0.2.117] (cardhu.semihalf.com. [213.17.239.108]) by mx.google.com with ESMTPSA id od6sm4052276bkb.11.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 27 Aug 2013 02:43:01 -0700 (PDT) Message-ID: <521C74A3.4050207@semihalf.com> Date: Tue, 27 Aug 2013 11:42:59 +0200 From: Zbyszek Bodek Organization: Semihalf User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130803 Thunderbird/17.0.8 MIME-Version: 1.0 To: fabiodive Subject: Re: HEADS UP: Superpages support for ARMv6/v7 References: <521BA6F6.3010308@semihalf.com> <0093E5B7-EC77-40AB-8AD4-0778E42993A6@gmail.com> In-Reply-To: <0093E5B7-EC77-40AB-8AD4-0778E42993A6@gmail.com> Content-Type: text/plain; charset=ISO-8859-1 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, 27 Aug 2013 11:31:48 -0000 On 27.08.2013 11:36, fabiodive wrote: > Hello, > I am going to do some tests on my beagle bone black here, > please could you give me an hint about enabling the feature > into the kernel? Which directive should I use? > thank you > f. > Hello. If you are not using loader then open: sys/arm/arm/pmap-v6.c and set "sp_enabled = 0;" -> "sp_enabled = 1;" recompile. OR if using loader then set: vm.pmap.sp_enabled=1 in loader.conf Both methods are sufficient. Best regards Zbigniew Bodek > On Aug 26, 2013, at 8:05 PM, Zbyszek Bodek wrote: > >> Hello Everyone. >> >> I'm happy to announce that Superpages support for ARM has just been >> integrated to the FreeBSD HEAD: >> http://svnweb.freebsd.org/changeset/base/254918 >> >> This project was sponsored by The FreeBSD Foundation and Semihalf. >> It was developed with great support of Alan Cox (alc) who was also the >> technical reviewer of the code. Thank you very much Alan for all your help! >> I would also like to thank Grzegorz Bernacki (gber) and Rafal Jaworowski >> (raj) for mentoring and help with the code integration and all the >> people involved in testing of the patches and review. >> >> The code was tested on a quad-core, ARMv7, Marvell Armada XP SoC in SMP >> environment. >> >> Superpages is a feature that can increase TLB coverage and allow for >> efficient use of page table entries. Current implementation for ARM >> supports two page sizes: 4KB small pages (used as base pages) and 1MB >> sections (used as superpages). >> Superpages are created either directly by 1MB section insertion or as a >> result of promotion of 256 4KB pages. In both cases superpages creation >> and utilization depends on *sp_enabled* sysctl variable. >> >> By default, superpages support is disabled. >> In order to use this functionality one needs to set >> *vm.pmap.sp_enabled* tunable to non-zero value. This can be done either >> in loader.conf or by modifying *sp_enabled* variable in >> sys/arm/arm/pmap-v6.c . Statistics regarding superpages usage are >> available through: sysctl vm.pmap.section >> >> All ARMv6/v7-based platforms can take advantage from superpages, so >> please enable this feature on your ARM kernels. >> We will appreciate all your feedback regarding performance impact and >> general system behavior. >> >> Performance improvement should be visible in all tasks where intensive >> memory utilization is involved. GUPS (Giga Updates Per Second) benchmark >> can be used to show the difference in memory utilization efficiency with >> superpages enabled and disabled. GUPS src can be downloaded from here: >> http://people.freebsd.org/~raj/patches/arm/superpages/GUPS.tar.gz >> >> Exemplary GUPS results: >> -------------------------------------------------------------------- >> *superpages enabled* >> vm.pmap.section.promotions: 1024 >> vm.pmap.section.p_failures: 58 >> vm.pmap.section.mappings: 0 >> vm.pmap.section.demotions: 0 >> >> # ./gups >> Main table size = 2^27 = 134217728 words >> Number of updates = 536870912 >> CPU time used = 97.085938 seconds >> Real time used = 97.082504 seconds >> 0.005530048 Billion(10^9) Updates per second [GUP/s] >> >> vm.pmap.section.promotions: 2048 >> vm.pmap.section.p_failures: 58 >> vm.pmap.section.mappings: 0 >> vm.pmap.section.demotions: 0 >> >> * superpages disabled * >> Main table size = 2^27 = 134217728 words >> Number of updates = 536870912 >> CPU time used = 145.679688 seconds >> Real time used = 145.680798 seconds >> 0.003685255 Billion(10^9) Updates per second [GUP/s] >> -------------------------------------------------------------------- >> >> *Self host buildworld* >> World build time on Armada XP has shortened from 6h 36min to >> 5h 14min with superpages enabled. >> >> *Stress tests* >> stress --cpu 4 --io 4 --vm 2 --vm-bytes 800M >> Survived long time runs, large superpages creation ratio has been observed. >> >> *Swapping* >> No problems with swapping or system running under heavy load with >> shortage of memory have been observed. >> >> >> Please feel free to send your results. >> >> Best regards >> Zbigniew Bodek >> _______________________________________________ >> 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 Aug 27 11:49:05 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 2CF92165 for ; Tue, 27 Aug 2013 11:49:05 +0000 (UTC) (envelope-from zbb@semihalf.com) Received: from mail-bk0-f42.google.com (mail-bk0-f42.google.com [209.85.214.42]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id AB3DD2164 for ; Tue, 27 Aug 2013 11:49:04 +0000 (UTC) Received: by mail-bk0-f42.google.com with SMTP id my10so1640858bkb.1 for ; Tue, 27 Aug 2013 04:49:02 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=dg1voK0bg7hxAeVGRZvD8ubuqvaxIk3uDfEvrcUxeFk=; b=BI2ogSab1GXaXycG2wezLJZQIHbEKJN+0bWaX351Vd1WFRIJpGlX8On0hTEU4xYQJJ 89GBPtc96zjeGbD3SmmdwiFHkIjTmrZmxl9F/1orH7TKQp+jRaqzgp2GvIBwyePJI+ff AIYN++UEU9lmf7vgY4lKHiyfbjeXLotq/pS4P9nYN5D7WUpbPnmnvjXE6oUZ5uE8CWvi bvsx1URHBGrFoKvvtlMrPoMswE8bpU7ome2f2LK9NgbyVJZqcAzzcZvpCm+72Erp8FGw LECpM669uWl2ZogCGtOmRojZ6vugvbg4f+e4J87rYQvTO7qg0TMaKr4N1K38SIQgeOUC 8VUA== X-Gm-Message-State: ALoCoQnjjIeXJOY1UYcMHR8fUHL+AfdsL9Qw25MVV9gXCYwGWqNpSEPyXFx47QytnpIbF35YM0gC X-Received: by 10.204.234.5 with SMTP id ka5mr3540059bkb.5.1377604142260; Tue, 27 Aug 2013 04:49:02 -0700 (PDT) Received: from [10.0.2.117] (cardhu.semihalf.com. [213.17.239.108]) by mx.google.com with ESMTPSA id pk7sm4292702bkb.2.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 27 Aug 2013 04:49:01 -0700 (PDT) Message-ID: <521C922B.6010200@semihalf.com> Date: Tue, 27 Aug 2013 13:48:59 +0200 From: Zbyszek Bodek Organization: Semihalf User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130803 Thunderbird/17.0.8 MIME-Version: 1.0 To: Andre Oppermann Subject: Re: ARM network trouble after recent mbuf changes References: <1377550636.1111.156.camel@revolution.hippie.lan> <521BC472.7040804@freebsd.org> <521BD531.4090104@sbcglobal.net> <521C4CD9.4050308@freebsd.org> <0E0536B2-2B7F-4EED-9EFD-4B9E2C2D729A@freebsd.org> <521C87FF.8010100@freebsd.org> In-Reply-To: <521C87FF.8010100@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Aug 2013 11:49:05 -0000 On 27.08.2013 13:05, Andre Oppermann wrote: > On 27.08.2013 11:38, Michael Tuexen wrote: >> On Aug 27, 2013, at 8:53 AM, Andre Oppermann wrote: >> >>> On 27.08.2013 00:22, Thomas Skibo wrote: >>>> On 8/26/13 2:11 PM, Andre Oppermann wrote: >>>>> >>>>> Can you try this patch see check if it makes a difference on the >>>>> bitfield? >>>> >>>> Actually, this works for me. But, I'm worried that somewhere else >>>> something is going to trip over a >>>> struct pkthdr not being 64-bit aligned. There are several 64-bit >>>> fields in there. >>> >>> The problem is the disconnect between the definition of MLEN and >>> MHLEN and >>> the effective size/padding of struct mbuf. That's the true bug. >>> >>> On LP64 all is fine. On i386 it turns out to be fine too because >>> doesn't >>> care. >>> >>> MLEN and MHLEN are incorrectly derived. In fact they should be >>> derived from >>> stuct mbuf where this padding would be taking into account. However >>> the way >>> it is structured right now it that would create a circular dependency. >>> >>> Please try the patch below to confirm. If it fixes your problem for now >>> I'm going to commit as an immediate fix while searching for a better >>> long >>> term stable solution. >>> >>> -- >>> Andre >>> >>> Index: sys/mbuf.h >>> =================================================================== >>> --- sys/mbuf.h (revision 254953) >>> +++ sys/mbuf.h (working copy) >>> @@ -94,6 +94,9 @@ >>> int32_t mh_len; /* amount of data in this >>> mbuf */ >>> uint32_t mh_type:8, /* type of data in this mbuf */ >>> mh_flags:24; /* flags; see below */ >>> +#if defined(__ILP32__) >>> + uint32_t mh_pad; /* pad to 64 bit alignment */ >>> +#endif >>> }; >> >> OK. It doesn't work. The reason is, that __ILP32__ is not defined... At >> lease I don't see it anywhere in the BSD stack. So I'm currently >> rebuilding >> with #if !defined(__LP64__) instead. I'll let you know... > > Thanks. I've changed the test accordingly. > > While doing the CTASSERTs to prevent such an incident in the future I > stumbled > across a bit of evil name space pollution in mbuf.h. It is impossible > to take > sizeof(struct m_ext) because "m_ext" is redefined to point into struct > mbuf. > > In addition to the alignment fix I've solved the namespace issues with > m_ext > and the stupidly named struct pkthdr as well and properly prefixed > them. The > fallout from LINT was zero (as it should be). > > http://people.freebsd.org/~andre/m_hdr-alignment-20130827.diff > > Please test. > Hello Andre. Works for me. Best regards Zbyszek Bodek From owner-freebsd-arm@FreeBSD.ORG Tue Aug 27 12:04: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 D522F6F7; Tue, 27 Aug 2013 12:04:46 +0000 (UTC) (envelope-from tuexen@freebsd.org) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 67ADC226D; Tue, 27 Aug 2013 12:04:46 +0000 (UTC) Received: from [192.168.1.200] (p508F3337.dip0.t-ipconnect.de [80.143.51.55]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 910BC1C0C0692; Tue, 27 Aug 2013 14:04:44 +0200 (CEST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Subject: Re: ARM network trouble after recent mbuf changes From: Michael Tuexen In-Reply-To: <521C87FF.8010100@freebsd.org> Date: Tue, 27 Aug 2013 14:04:43 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <30F80BE6-9580-4166-BD12-09AABD65CCE5@freebsd.org> References: <1377550636.1111.156.camel@revolution.hippie.lan> <521BC472.7040804@freebsd.org> <521BD531.4090104@sbcglobal.net> <521C4CD9.4050308@freebsd.org> <0E0536B2-2B7F-4EED-9EFD-4B9E2C2D729A@freebsd.org> <521C87FF.8010100@freebsd.org> To: Andre Oppermann 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: Tue, 27 Aug 2013 12:04:47 -0000 On Aug 27, 2013, at 1:05 PM, Andre Oppermann wrote: > On 27.08.2013 11:38, Michael Tuexen wrote: >> On Aug 27, 2013, at 8:53 AM, Andre Oppermann = wrote: >>=20 >>> On 27.08.2013 00:22, Thomas Skibo wrote: >>>> On 8/26/13 2:11 PM, Andre Oppermann wrote: >>>>>=20 >>>>> Can you try this patch see check if it makes a difference on the = bitfield? >>>>=20 >>>> Actually, this works for me. But, I'm worried that somewhere else = something is going to trip over a >>>> struct pkthdr not being 64-bit aligned. There are several 64-bit = fields in there. >>>=20 >>> The problem is the disconnect between the definition of MLEN and = MHLEN and >>> the effective size/padding of struct mbuf. That's the true bug. >>>=20 >>> On LP64 all is fine. On i386 it turns out to be fine too because = doesn't >>> care. >>>=20 >>> MLEN and MHLEN are incorrectly derived. In fact they should be = derived from >>> stuct mbuf where this padding would be taking into account. However = the way >>> it is structured right now it that would create a circular = dependency. >>>=20 >>> Please try the patch below to confirm. If it fixes your problem for = now >>> I'm going to commit as an immediate fix while searching for a better = long >>> term stable solution. >>>=20 >>> -- >>> Andre >>>=20 >>> Index: sys/mbuf.h >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>> --- sys/mbuf.h (revision 254953) >>> +++ sys/mbuf.h (working copy) >>> @@ -94,6 +94,9 @@ >>> int32_t mh_len; /* amount of data in this = mbuf */ >>> uint32_t mh_type:8, /* type of data in this mbuf = */ >>> mh_flags:24; /* flags; see below */ >>> +#if defined(__ILP32__) >>> + uint32_t mh_pad; /* pad to 64 bit alignment = */ >>> +#endif >>> }; > > >> OK. It doesn't work. The reason is, that __ILP32__ is not defined... = At >> lease I don't see it anywhere in the BSD stack. So I'm currently = rebuilding >> with #if !defined(__LP64__) instead. I'll let you know... >=20 > Thanks. I've changed the test accordingly. Great. My testing of the !defined(__LP64__) stuff shows that it works. >=20 >=20 > While doing the CTASSERTs to prevent such an incident in the future I = stumbled > across a bit of evil name space pollution in mbuf.h. It is impossible = to take > sizeof(struct m_ext) because "m_ext" is redefined to point into struct = mbuf. >=20 > In addition to the alignment fix I've solved the namespace issues with = m_ext > and the stupidly named struct pkthdr as well and properly prefixed = them. The > fallout from LINT was zero (as it should be). >=20 > http://people.freebsd.org/~andre/m_hdr-alignment-20130827.diff >=20 > Please test. I'll do and let you know. It takes a couple of hours. The patch looks good... Best regards Michael >=20 > --=20 > Andre >=20 > From owner-freebsd-arm@FreeBSD.ORG Tue Aug 27 12:36: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 3FF63B5A for ; Tue, 27 Aug 2013 12:36:04 +0000 (UTC) (envelope-from lists.br@gmail.com) Received: from mail-wg0-x22c.google.com (mail-wg0-x22c.google.com [IPv6:2a00:1450:400c:c00::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id CAEF92411 for ; Tue, 27 Aug 2013 12:36:03 +0000 (UTC) Received: by mail-wg0-f44.google.com with SMTP id x12so3325456wgg.11 for ; Tue, 27 Aug 2013 05:36:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=E4o1vRpCiq7Y+m5Rx9oFNT91j9zcn+uCGeskBXFi9bQ=; b=UYuMrF/e3Tk6byw1Fh3LUyIJZX+yfYhfzSNFxzjvkUa+uQ39RZJnK7qr/vOWBuv2pT ni3tjtWEE5HNQCOA/i4DIe+JMLQ4PyDtZtlRm0kxjA3jUyGxzs3nLfzCQBE72xk70F+w RJ3iTMsZjAy79ITKgK0PXel6+Mjs1X0gl5KiV1fOG7QdQLBJi6OQYqXrqmNEK9kWtyI0 RtLksl9q4Xh+ezgeVP7+TpZjpFCjCl5sVd9+AmEmwRQrNXSA5U9Ajz04la+yiMNcYggT 4dZj7x3+yObi6k2fk9qgz3FUl04FkUB1SaO4K9KFTMrlG0FGdUGjxZ7bUb6t2Gb7hlZe zgkQ== MIME-Version: 1.0 X-Received: by 10.180.187.41 with SMTP id fp9mr11180091wic.33.1377606962088; Tue, 27 Aug 2013 05:36:02 -0700 (PDT) Received: by 10.216.75.140 with HTTP; Tue, 27 Aug 2013 05:36:02 -0700 (PDT) In-Reply-To: References: <126AAEEA-1F99-42E4-9620-9CB4F3610671@gmail.com> Date: Tue, 27 Aug 2013 09:36:02 -0300 Message-ID: Subject: Re: SPI driver for RPi 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" , Luiz Otavio O Souza 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, 27 Aug 2013 12:36:04 -0000 On 25 August 2013 11:12, fabiodive wrote: > Hello Luiz, > after applying the patches, > should I compile the kernel with the "device api" written into the kernel > config file? > thank you, > f. No, it is not needed and actually, there is no 'device spi' defined in kernel. SPI in general is handled by 'device spibus' plus the specific driver for your hardware, bcm2835_spi in this case. Luiz From owner-freebsd-arm@FreeBSD.ORG Tue Aug 27 13:22:38 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 442B0A08 for ; Tue, 27 Aug 2013 13:22:38 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-ie0-f170.google.com (mail-ie0-f170.google.com [209.85.223.170]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 0F801272E for ; Tue, 27 Aug 2013 13:22:37 +0000 (UTC) Received: by mail-ie0-f170.google.com with SMTP id 17so7581602iea.29 for ; Tue, 27 Aug 2013 06:22:37 -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=AGxwDvvA05I8VlFT7Xiy4W/3p8pmdKku1/4LpQtsyZo=; b=T+7TUMQeyxLrZ1B8iweMy04EON8r7Y+lqoL1hyov3/0k5SgWR6pSvfHuf0HNN7d5XE 05bWbbFHwhGie8mLrM4/1J809/UJb+bBe4pwlhD3s9G9oGvXoBqSPOFVnKVJjkjMOciE 3/VosyT64dGFFaIfmli+Zlwbc9FqYEXPd3IiH6HBxgY/flvRB6XV3tKtyyuj9JWVGZD9 OitNXHLhKqBRyM//PfdhOVtgaNRBMlghZB3VVzeqT/1izZ/BmykTCKSUek/qeOoecBXT E8nGZeu4nRQEIVVXFBHmDgbElf6yKl0sgHIKZ198fM7B1TZ5LQbIAmHayGiVZuWd0off eqEQ== X-Gm-Message-State: ALoCoQlqFiQuSy+gt8iLWSxSLypGKgfO4OsLAWaGZoYL65LJ8c6d6fLdhUBoFwbPTREEilUAYd2r X-Received: by 10.50.39.51 with SMTP id m19mr9927498igk.51.1377609754504; Tue, 27 Aug 2013 06:22:34 -0700 (PDT) Received: from [10.0.0.53] (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPSA id ft2sm24365867igb.5.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 27 Aug 2013 06:22:33 -0700 (PDT) Sender: Warner Losh Subject: Re: ARM network trouble after recent mbuf changes Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <521C3EE4.80801@bitfrost.no> Date: Tue, 27 Aug 2013 07:22:30 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <16DC29EA-9D4D-4A57-8C16-913C344101C6@bsdimp.com> References: <1377550636.1111.156.camel@revolution.hippie.lan> <521BC472.7040804@freebsd.org> <521BD531.4090104@sbcglobal.net> <521C3EE4.80801@bitfrost.no> To: Hans Petter Selasky X-Mailer: Apple Mail (2.1085) Cc: Andre Oppermann , freebsd-arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Aug 2013 13:22:38 -0000 On Aug 26, 2013, at 11:53 PM, Hans Petter Selasky wrote: > On 08/27/13 00:38, Michael Tuexen wrote: >> I did some tests with a small program. Having in struct pkthdr 64 bit = entities >> results in a 64 bit alignment when used in struct mbuf. Using = __packed >> for struct mbuf, removes the padding. >=20 >=20 > Hi, >=20 > Maybe you could use __aligned(8) instead, and account for the extra = padding on all platforms? Packed has other disadvantages on ARM = platforms when accessing the structures, like that non-aligned access is = possible, and that it is sometimes slower than aligned access. Yes, __packed is generally a really bad idea for in-memory, performance = critical structures. In this case, __aligned(8) I don't think would have = much of an effect since the problem is a mismatch between MLEN and its = actual length (shame on whoever didn't put a compile time assert in = there).... Warner From owner-freebsd-arm@FreeBSD.ORG Tue Aug 27 13:24: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 4E442BE3 for ; Tue, 27 Aug 2013 13:24:18 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-ie0-f170.google.com (mail-ie0-f170.google.com [209.85.223.170]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 1B9212748 for ; Tue, 27 Aug 2013 13:24:17 +0000 (UTC) Received: by mail-ie0-f170.google.com with SMTP id 17so7585280iea.29 for ; Tue, 27 Aug 2013 06:24:17 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; 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=1CJ92Z8C3uJUA56ZtWCRRe4lnkPP9fKxjRfSwJFgSqI=; b=dWYtvAMVQj+AiOm+sHTaFHc18hixW0w/YUfcAvBGUOv3rNL2R6YvSOTNiD5NEBsIQT iG+vZnrzJL1WgjEGMFRh3adntUGK6ytoYlx2UA7er7Q48huKmXa0VjR14LVP2Sl9a1/z Z5ZoXd9w2coReeLBXnM1h5Oal8A8eNAAqm5AIlyK82x/VTomAz/6N38TiYmhp+JoRfPY LA25zRURTgOMnLhDdbHUg2tUuBw3M+5OHWcaaBbYJBmV9jhsBeEKrFoVlfhRnvmDzKtB HVkyy+4HsMtyRf0yoGeU0v4eh9NF/Zi0itOAwbtMAAuV+hUdTcsKzZTjYAIcQYkD3Y6K RZWQ== X-Gm-Message-State: ALoCoQnjQAY/s4hy25Zku7d1/j3gv8LGfX6tZ1SDSGhesFxesKacHHwlbWIwpl8xe7IXYCRVDdr5 X-Received: by 10.50.26.36 with SMTP id i4mr10041250igg.33.1377609856349; Tue, 27 Aug 2013 06:24:16 -0700 (PDT) Received: from [10.0.0.53] (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPSA id w4sm24365505igb.5.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 27 Aug 2013 06:24:15 -0700 (PDT) Sender: Warner Losh Subject: Re: ARM network trouble after recent mbuf changes Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <521C4CD9.4050308@freebsd.org> Date: Tue, 27 Aug 2013 07:24:13 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <40769440-B167-4817-9855-1CAB09081AF8@bsdimp.com> References: <1377550636.1111.156.camel@revolution.hippie.lan> <521BC472.7040804@freebsd.org> <521BD531.4090104@sbcglobal.net> <521C4CD9.4050308@freebsd.org> To: Andre Oppermann 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: Tue, 27 Aug 2013 13:24:18 -0000 On Aug 27, 2013, at 12:53 AM, Andre Oppermann wrote: > On 27.08.2013 00:22, Thomas Skibo wrote: >> On 8/26/13 2:11 PM, Andre Oppermann wrote: >>>=20 >>> Can you try this patch see check if it makes a difference on the = bitfield? >>=20 >> Actually, this works for me. But, I'm worried that somewhere else = something is going to trip over a >> struct pkthdr not being 64-bit aligned. There are several 64-bit = fields in there. >=20 > The problem is the disconnect between the definition of MLEN and MHLEN = and > the effective size/padding of struct mbuf. That's the true bug. >=20 > On LP64 all is fine. On i386 it turns out to be fine too because = doesn't > care. >=20 > MLEN and MHLEN are incorrectly derived. In fact they should be = derived from > stuct mbuf where this padding would be taking into account. However = the way > it is structured right now it that would create a circular dependency. >=20 > Please try the patch below to confirm. If it fixes your problem for = now > I'm going to commit as an immediate fix while searching for a better = long > term stable solution. >=20 > --=20 > Andre >=20 > Index: sys/mbuf.h > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- sys/mbuf.h (revision 254953) > +++ sys/mbuf.h (working copy) > @@ -94,6 +94,9 @@ > int32_t mh_len; /* amount of data in this mbuf = */ > uint32_t mh_type:8, /* type of data in this mbuf */ > mh_flags:24; /* flags; see below */ > +#if defined(__ILP32__) > + uint32_t mh_pad; /* pad to 64 bit alignment */ > +#endif > }; >=20 > /* There should be a CTASSERT() here to make sure there's no mismatch... Warner= From owner-freebsd-arm@FreeBSD.ORG Tue Aug 27 13:25: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 C08CEC2B for ; Tue, 27 Aug 2013 13:25:12 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-ie0-f182.google.com (mail-ie0-f182.google.com [209.85.223.182]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 8B65D2752 for ; Tue, 27 Aug 2013 13:25:12 +0000 (UTC) Received: by mail-ie0-f182.google.com with SMTP id aq17so7491116iec.27 for ; Tue, 27 Aug 2013 06:25:06 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; 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=g/NjVfgm13EwwWvDKFx6xeLJYqvYhVNcFTIFysQCHoE=; b=baT/bQkORjs/CoeidDEPyAId0GOlkBc/SmKbOLSzEPc7CTda4CBw9qUolOfs/XqBxD hmenZ5w2GWHeHartqrns1V6vQIXs0sUgIpICWANi9nxKseBZzW0tVljtfsaJ/6SHAoQm F2WDGkbY0Gm6Vboi3bX5YY7x+pTgIDZG2O5Gc+MQWjCgBDt7Asj4IXuOR3iGwZRLK2hQ Z6AS/+ufeMtYyrjuqVhW2KL+00/nGeNvy4JYSLKJa/bIVuLxwDl2WhGabCkNN77v3iaX uFjtokZTdSml6htmg5Nzk7tc3HerHq/xvXkfEdahoAH2BBizlRn4t2/2wTLQI/cHnb+O nSbw== X-Gm-Message-State: ALoCoQli+TX9CBSfZUDDTeNyJ/Jm+Mzj005Fa8dVxSR+YK1gMTW8OaIRJdr2MS/I5Q2zw4bNft28 X-Received: by 10.42.52.129 with SMTP id j1mr10092566icg.5.1377609906311; Tue, 27 Aug 2013 06:25:06 -0700 (PDT) Received: from [10.0.0.53] (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPSA id w4sm24365505igb.5.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 27 Aug 2013 06:25:05 -0700 (PDT) Sender: Warner Losh Subject: Re: ARM network trouble after recent mbuf changes Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <627451FE-4F20-4E4D-9B24-59E0F340EF75@freebsd.org> Date: Tue, 27 Aug 2013 07:25:04 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1377550636.1111.156.camel@revolution.hippie.lan> <521BC472.7040804@freebsd.org> <521BD531.4090104@sbcglobal.net> <521C3EE4.80801@bitfrost.no> <3F762A16-3760-4FAA-B547-27529032AFEA@freebsd.org> <521C4CE3.9080400@freebsd.org> <627451FE-4F20-4E4D-9B24-59E0F340EF75@freebsd.org> To: Michael Tuexen X-Mailer: Apple Mail (2.1085) Cc: freebsd-arm , Andre Oppermann 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, 27 Aug 2013 13:25:12 -0000 On Aug 27, 2013, at 12:58 AM, Michael Tuexen wrote: > On Aug 27, 2013, at 8:53 AM, Andre Oppermann = wrote: >=20 >> On 27.08.2013 08:30, Michael Tuexen wrote: >>> On Aug 27, 2013, at 7:53 AM, Hans Petter Selasky = wrote: >>>=20 >>>> On 08/27/13 00:38, Michael Tuexen wrote: >>>>> I did some tests with a small program. Having in struct pkthdr 64 = bit entities >>>>> results in a 64 bit alignment when used in struct mbuf. Using = __packed >>>>> for struct mbuf, removes the padding. >>>>=20 >>>>=20 >>>> Hi, >>>>=20 >>>> Maybe you could use __aligned(8) instead, and account for the extra = padding on all platforms? Packed has other disadvantages on ARM = platforms when accessing the structures, like that non-aligned access is = possible, and that it is sometimes slower than aligned access. >>> Isn't there a performance penalty when accessing 64-bit entities not = being 64-bit >>> aligned? If that is the case, wouldn't it make sense to add a 4 byte = padding to >>> struct m_hdr for ILP32? Then the problem should go away... >>=20 >> Either that or define MLEN and MHLEN in a way that actually reflects = the true >> size of what they are representing. The latter is the true bug. > Correct. There is the hidden assumption that there is no padding. = Maybe you can > put that in a comment... Maybe we can have it as a CTASSERT. Better than any comment. CTASSERTS = are free and catch this kind of thing... > We could also have some code (maybe under INVARIANTS) where we check = that > an struct mbuf has the size MSIZE and panic if not. > This would make things clearer if the problem happens again. >>=20 >>> We could also get rid of the 64 bit alignment by not having 64-bit = entities in >>> struct pkthdr. Removing sixtyfour should be easy. However, we now = have also >>> uint64_t csum_flags. >>=20 >> Yes, the 64 bit fields are to be used to store packet associated = information >> on its way through the stack. Reducing it to 32 bits would somewhat = defeat >> their purpose. > I completely agree... >>=20 >> --=20 >> Andre >>=20 >>=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" From owner-freebsd-arm@FreeBSD.ORG Tue Aug 27 13:26: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 A3D4AC74 for ; Tue, 27 Aug 2013 13:26:10 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-ie0-f181.google.com (mail-ie0-f181.google.com [209.85.223.181]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 71B60275D for ; Tue, 27 Aug 2013 13:26:10 +0000 (UTC) Received: by mail-ie0-f181.google.com with SMTP id a14so7225279iee.40 for ; Tue, 27 Aug 2013 06:26:04 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; 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=M2ER/tkQRYx3zKPJ7Mmf0LxG+1z6h+sh7uV8bpWvHHI=; b=NlCPqS51tte0NAy1q2z5nVmxAFuNtXhtk18jk0ir0PXAIXhIBMdU5tSrg5KnpdivsU ES8+DqqI3ax8V+mYXWvwjk7yvNDwgmizdZ46pqNoJJxIHHyWeqew88+kpQWp3WLmWHDT iyMDnP0rUtJbi0KfiVwy0zxH+DAnjQdepSHWVLudasO00qFmxmatNkQY0NyLk941BZUy 8fSm8idT645pTn/AvEWKkZBqaxDxmOD84q23vJZufxuALdlpn4i2ulLuzIqRrOIJ70hB dYuWdjtlPXu9/PEqAvkUSR4m/tIdDnLYMHAumG308w5gbofx/veYAQ4TiWmI2+yMoPxP n3bQ== X-Gm-Message-State: ALoCoQkLFOVynsiMFGGkqaoC2dFSGSVzhVs87pGSBRM7xRL0Tb5ihfvLt0bkz7+M2vIMpap5VxLf X-Received: by 10.43.111.5 with SMTP id em5mr1062966icc.40.1377609964385; Tue, 27 Aug 2013 06:26:04 -0700 (PDT) Received: from [10.0.0.53] (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPSA id w4sm24365505igb.5.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 27 Aug 2013 06:26:03 -0700 (PDT) Sender: Warner Losh Subject: Re: ARM network trouble after recent mbuf changes Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <20130827102810.37e2dfc7@bender> Date: Tue, 27 Aug 2013 07:26:03 -0600 Content-Transfer-Encoding: 7bit Message-Id: References: <1377550636.1111.156.camel@revolution.hippie.lan> <521BC472.7040804@freebsd.org> <521BD531.4090104@sbcglobal.net> <521C4CD9.4050308@freebsd.org> <20130827102810.37e2dfc7@bender> To: Andrew Turner X-Mailer: Apple Mail (2.1085) Cc: freebsd-arm , Andre Oppermann 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, 27 Aug 2013 13:26:10 -0000 On Aug 27, 2013, at 3:28 AM, Andrew Turner wrote: > On Tue, 27 Aug 2013 08:53:13 +0200 > Andre Oppermann wrote: >> Please try the patch below to confirm. If it fixes your problem for >> now I'm going to commit as an immediate fix while searching for a >> better long term stable solution. >> > > I tried this with a CTASSERT to check if struct m_hdr is the correct > length. In this test the size is incorrect. It appears __ILP32__ is not > defined on ARM. > > I have tested a fix suggested by Hans Petter Selasky where we mark > m_hdr with __aligned(8). With this change I can netboot a PandaBoard. Isn't that a bug with our arm compiler then? Warner From owner-freebsd-arm@FreeBSD.ORG Tue Aug 27 13:29: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 26F0AD0B; Tue, 27 Aug 2013 13:29:42 +0000 (UTC) (envelope-from tuexen@freebsd.org) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id AD7362785; Tue, 27 Aug 2013 13:29:41 +0000 (UTC) Received: from [192.168.1.200] (p508F3337.dip0.t-ipconnect.de [80.143.51.55]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id E216E1C0C0692; Tue, 27 Aug 2013 15:29:37 +0200 (CEST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Subject: Re: ARM network trouble after recent mbuf changes From: Michael Tuexen In-Reply-To: <521C87FF.8010100@freebsd.org> Date: Tue, 27 Aug 2013 15:29:37 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1377550636.1111.156.camel@revolution.hippie.lan> <521BC472.7040804@freebsd.org> <521BD531.4090104@sbcglobal.net> <521C4CD9.4050308@freebsd.org> <0E0536B2-2B7F-4EED-9EFD-4B9E2C2D729A@freebsd.org> <521C87FF.8010100@freebsd.org> To: Andre Oppermann 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: Tue, 27 Aug 2013 13:29:42 -0000 On Aug 27, 2013, at 1:05 PM, Andre Oppermann wrote: > On 27.08.2013 11:38, Michael Tuexen wrote: >> On Aug 27, 2013, at 8:53 AM, Andre Oppermann = wrote: >>=20 >>> On 27.08.2013 00:22, Thomas Skibo wrote: >>>> On 8/26/13 2:11 PM, Andre Oppermann wrote: >>>>>=20 >>>>> Can you try this patch see check if it makes a difference on the = bitfield? >>>>=20 >>>> Actually, this works for me. But, I'm worried that somewhere else = something is going to trip over a >>>> struct pkthdr not being 64-bit aligned. There are several 64-bit = fields in there. >>>=20 >>> The problem is the disconnect between the definition of MLEN and = MHLEN and >>> the effective size/padding of struct mbuf. That's the true bug. >>>=20 >>> On LP64 all is fine. On i386 it turns out to be fine too because = doesn't >>> care. >>>=20 >>> MLEN and MHLEN are incorrectly derived. In fact they should be = derived from >>> stuct mbuf where this padding would be taking into account. However = the way >>> it is structured right now it that would create a circular = dependency. >>>=20 >>> Please try the patch below to confirm. If it fixes your problem for = now >>> I'm going to commit as an immediate fix while searching for a better = long >>> term stable solution. >>>=20 >>> -- >>> Andre >>>=20 >>> Index: sys/mbuf.h >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>> --- sys/mbuf.h (revision 254953) >>> +++ sys/mbuf.h (working copy) >>> @@ -94,6 +94,9 @@ >>> int32_t mh_len; /* amount of data in this = mbuf */ >>> uint32_t mh_type:8, /* type of data in this mbuf = */ >>> mh_flags:24; /* flags; see below */ >>> +#if defined(__ILP32__) >>> + uint32_t mh_pad; /* pad to 64 bit alignment = */ >>> +#endif >>> }; > > >> OK. It doesn't work. The reason is, that __ILP32__ is not defined... = At >> lease I don't see it anywhere in the BSD stack. So I'm currently = rebuilding >> with #if !defined(__LP64__) instead. I'll let you know... >=20 > Thanks. I've changed the test accordingly. >=20 > While doing the CTASSERTs to prevent such an incident in the future I = stumbled > across a bit of evil name space pollution in mbuf.h. It is impossible = to take > sizeof(struct m_ext) because "m_ext" is redefined to point into struct = mbuf. >=20 > In addition to the alignment fix I've solved the namespace issues with = m_ext > and the stupidly named struct pkthdr as well and properly prefixed = them. The > fallout from LINT was zero (as it should be). >=20 > http://people.freebsd.org/~andre/m_hdr-alignment-20130827.diff >=20 > Please test. Done. r254954 with your patch applied runs fine on a RPi. Best regards Michael >=20 > --=20 > Andre >=20 > From owner-freebsd-arm@FreeBSD.ORG Tue Aug 27 13:42:03 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 75C0F35E; Tue, 27 Aug 2013 13:42:03 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-qe0-x22e.google.com (mail-qe0-x22e.google.com [IPv6:2607:f8b0:400d:c02::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 24A932864; Tue, 27 Aug 2013 13:42:03 +0000 (UTC) Received: by mail-qe0-f46.google.com with SMTP id f6so2583243qej.33 for ; Tue, 27 Aug 2013 06:42:02 -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=/+4a0OFjliKStnSESC/XK34n5oI3yVG5CagQFYYYgWQ=; b=TbL7Q4vvxSLgyI1mzOUvjhpdB+9ocO3ZyHts9oGG8u+Il5ZNdU12jMFKzmmvcoiTod 3Z6ixhaZtV/2HAV8UTVsLy9c7uSSgxk/Ov9ufLBIEvlXoXD0oaEIFEx5SwtNkGpbB741 4qo/GWmwmEvfpoVPjxW4zN9DdWlbmKXN4zZVtTdJllDWrFdfNw778wWAf2JFcoNyro1T NzZnSO05u1+ZBVeKUuzpgsSUUvQjtFGUCGJFVCVbxFYlFGKbznEkbaIB2xO5YLTpV2Nw xC7mmphFxnD99n2E80IDLfqND2xaBSnev5dHNGe3ZEv+wdH/kJXiE2t3rf/9Xv9NVgy7 wUzg== MIME-Version: 1.0 X-Received: by 10.49.62.3 with SMTP id u3mr23328995qer.6.1377610922269; Tue, 27 Aug 2013 06:42:02 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.224.128.70 with HTTP; Tue, 27 Aug 2013 06:42:02 -0700 (PDT) In-Reply-To: <40769440-B167-4817-9855-1CAB09081AF8@bsdimp.com> References: <1377550636.1111.156.camel@revolution.hippie.lan> <521BC472.7040804@freebsd.org> <521BD531.4090104@sbcglobal.net> <521C4CD9.4050308@freebsd.org> <40769440-B167-4817-9855-1CAB09081AF8@bsdimp.com> Date: Tue, 27 Aug 2013 06:42:02 -0700 X-Google-Sender-Auth: rW7h-mQgg__S0bm7l79VMPHxJmY Message-ID: Subject: Re: ARM network trouble after recent mbuf changes From: Adrian Chadd To: Warner Losh Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-arm , Andre Oppermann 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, 27 Aug 2013 13:42:03 -0000 +1 -adrian On 27 August 2013 06:24, Warner Losh wrote: > > On Aug 27, 2013, at 12:53 AM, Andre Oppermann wrote: > > > On 27.08.2013 00:22, Thomas Skibo wrote: > >> On 8/26/13 2:11 PM, Andre Oppermann wrote: > >>> > >>> Can you try this patch see check if it makes a difference on the > bitfield? > >> > >> Actually, this works for me. But, I'm worried that somewhere else > something is going to trip over a > >> struct pkthdr not being 64-bit aligned. There are several 64-bit > fields in there. > > > > The problem is the disconnect between the definition of MLEN and MHLEN > and > > the effective size/padding of struct mbuf. That's the true bug. > > > > On LP64 all is fine. On i386 it turns out to be fine too because doesn't > > care. > > > > MLEN and MHLEN are incorrectly derived. In fact they should be derived > from > > stuct mbuf where this padding would be taking into account. However the > way > > it is structured right now it that would create a circular dependency. > > > > Please try the patch below to confirm. If it fixes your problem for now > > I'm going to commit as an immediate fix while searching for a better long > > term stable solution. > > > > -- > > Andre > > > > Index: sys/mbuf.h > > =================================================================== > > --- sys/mbuf.h (revision 254953) > > +++ sys/mbuf.h (working copy) > > @@ -94,6 +94,9 @@ > > int32_t mh_len; /* amount of data in this mbuf */ > > uint32_t mh_type:8, /* type of data in this mbuf */ > > mh_flags:24; /* flags; see below */ > > +#if defined(__ILP32__) > > + uint32_t mh_pad; /* pad to 64 bit alignment */ > > +#endif > > }; > > > > /* > > There should be a CTASSERT() here to make sure there's no mismatch... > > Warner > _______________________________________________ > 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 Aug 27 13:44:24 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 298013E4 for ; Tue, 27 Aug 2013 13:44:24 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 734772886 for ; Tue, 27 Aug 2013 13:44:23 +0000 (UTC) Received: (qmail 13756 invoked from network); 27 Aug 2013 14:26:17 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 27 Aug 2013 14:26:17 -0000 Message-ID: <521CAD2C.3080202@freebsd.org> Date: Tue, 27 Aug 2013 15:44:12 +0200 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Adrian Chadd Subject: Re: ARM network trouble after recent mbuf changes References: <1377550636.1111.156.camel@revolution.hippie.lan> <521BC472.7040804@freebsd.org> <521BD531.4090104@sbcglobal.net> <521C4CD9.4050308@freebsd.org> <40769440-B167-4817-9855-1CAB09081AF8@bsdimp.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Aug 2013 13:44:24 -0000 On 27.08.2013 15:42, Adrian Chadd wrote: > +1 Please see my later email with a patch that does all this. :) -- Andre > -adrian > > > On 27 August 2013 06:24, Warner Losh > wrote: > > > On Aug 27, 2013, at 12:53 AM, Andre Oppermann wrote: > > > On 27.08.2013 00:22, Thomas Skibo wrote: > >> On 8/26/13 2:11 PM, Andre Oppermann wrote: > >>> > >>> Can you try this patch see check if it makes a difference on the bitfield? > >> > >> Actually, this works for me. But, I'm worried that somewhere else something is going to > trip over a > >> struct pkthdr not being 64-bit aligned. There are several 64-bit fields in there. > > > > The problem is the disconnect between the definition of MLEN and MHLEN and > > the effective size/padding of struct mbuf. That's the true bug. > > > > On LP64 all is fine. On i386 it turns out to be fine too because doesn't > > care. > > > > MLEN and MHLEN are incorrectly derived. In fact they should be derived from > > stuct mbuf where this padding would be taking into account. However the way > > it is structured right now it that would create a circular dependency. > > > > Please try the patch below to confirm. If it fixes your problem for now > > I'm going to commit as an immediate fix while searching for a better long > > term stable solution. > > > > -- > > Andre > > > > Index: sys/mbuf.h > > =================================================================== > > --- sys/mbuf.h (revision 254953) > > +++ sys/mbuf.h (working copy) > > @@ -94,6 +94,9 @@ > > int32_t mh_len; /* amount of data in this mbuf */ > > uint32_t mh_type:8, /* type of data in this mbuf */ > > mh_flags:24; /* flags; see below */ > > +#if defined(__ILP32__) > > + uint32_t mh_pad; /* pad to 64 bit alignment */ > > +#endif > > }; > > > > /* > > There should be a CTASSERT() here to make sure there's no mismatch... > > Warner > _______________________________________________ > 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 Aug 27 14:23:45 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 8EB1222F for ; Tue, 27 Aug 2013 14:23:45 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id F3B6B2B1F for ; Tue, 27 Aug 2013 14:23:44 +0000 (UTC) Received: (qmail 13884 invoked from network); 27 Aug 2013 15:05:44 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 27 Aug 2013 15:05:44 -0000 Message-ID: <521CB66B.9020806@freebsd.org> Date: Tue, 27 Aug 2013 16:23:39 +0200 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Michael Tuexen Subject: Re: ARM network trouble after recent mbuf changes References: <1377550636.1111.156.camel@revolution.hippie.lan> <521BC472.7040804@freebsd.org> <521BD531.4090104@sbcglobal.net> <521C4CD9.4050308@freebsd.org> <0E0536B2-2B7F-4EED-9EFD-4B9E2C2D729A@freebsd.org> <521C87FF.8010100@freebsd.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Aug 2013 14:23:45 -0000 On 27.08.2013 15:29, Michael Tuexen wrote: > On Aug 27, 2013, at 1:05 PM, Andre Oppermann wrote: >> Thanks. I've changed the test accordingly. >> >> While doing the CTASSERTs to prevent such an incident in the future I stumbled >> across a bit of evil name space pollution in mbuf.h. It is impossible to take >> sizeof(struct m_ext) because "m_ext" is redefined to point into struct mbuf. >> >> In addition to the alignment fix I've solved the namespace issues with m_ext >> and the stupidly named struct pkthdr as well and properly prefixed them. The >> fallout from LINT was zero (as it should be). >> >> http://people.freebsd.org/~andre/m_hdr-alignment-20130827.diff >> >> Please test. > > Done. r254954 with your patch applied runs fine on a RPi. Does the CTASSERT trigger if the padding in m_hdr is not there? -- Andre From owner-freebsd-arm@FreeBSD.ORG Tue Aug 27 14:27:22 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 398222E3; Tue, 27 Aug 2013 14:27:22 +0000 (UTC) (envelope-from tuexen@freebsd.org) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id C05F02B58; Tue, 27 Aug 2013 14:27:21 +0000 (UTC) Received: from [192.168.1.200] (p508F3337.dip0.t-ipconnect.de [80.143.51.55]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 135041C0C069C; Tue, 27 Aug 2013 16:27:20 +0200 (CEST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Subject: Re: ARM network trouble after recent mbuf changes From: Michael Tuexen In-Reply-To: <521CB66B.9020806@freebsd.org> Date: Tue, 27 Aug 2013 16:27:19 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <0833E93A-BD62-4312-88D6-61E60CE6BCF6@freebsd.org> References: <1377550636.1111.156.camel@revolution.hippie.lan> <521BC472.7040804@freebsd.org> <521BD531.4090104@sbcglobal.net> <521C4CD9.4050308@freebsd.org> <0E0536B2-2B7F-4EED-9EFD-4B9E2C2D729A@freebsd.org> <521C87FF.8010100@freebsd.org> <521CB66B.9020806@freebsd.org> To: Andre Oppermann 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: Tue, 27 Aug 2013 14:27:22 -0000 On Aug 27, 2013, at 4:23 PM, Andre Oppermann wrote: > On 27.08.2013 15:29, Michael Tuexen wrote: >> On Aug 27, 2013, at 1:05 PM, Andre Oppermann = wrote: >>> Thanks. I've changed the test accordingly. >>>=20 >>> While doing the CTASSERTs to prevent such an incident in the future = I stumbled >>> across a bit of evil name space pollution in mbuf.h. It is = impossible to take >>> sizeof(struct m_ext) because "m_ext" is redefined to point into = struct mbuf. >>>=20 >>> In addition to the alignment fix I've solved the namespace issues = with m_ext >>> and the stupidly named struct pkthdr as well and properly prefixed = them. The >>> fallout from LINT was zero (as it should be). >>>=20 >>> http://people.freebsd.org/~andre/m_hdr-alignment-20130827.diff >>>=20 >>> Please test. > > >> Done. r254954 with your patch applied runs fine on a RPi. >=20 > Does the CTASSERT trigger if the padding in m_hdr is not there? Testing... Best regards Michael >=20 > --=20 > Andre >=20 >=20 From owner-freebsd-arm@FreeBSD.ORG Tue Aug 27 14:57:45 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 136E41E9; Tue, 27 Aug 2013 14:57:45 +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 D9FB52D76; Tue, 27 Aug 2013 14:57:44 +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 1VEKi9-000ENG-P7; Tue, 27 Aug 2013 14:57:37 +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 r7REvZoN053205; Tue, 27 Aug 2013 08:57:35 -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: U2FsdGVkX18RprrW0s8eih+vtyKfEZTs Subject: Re: ARM network trouble after recent mbuf changes From: Ian Lepore To: Andre Oppermann In-Reply-To: <521CB66B.9020806@freebsd.org> References: <1377550636.1111.156.camel@revolution.hippie.lan> <521BC472.7040804@freebsd.org> <521BD531.4090104@sbcglobal.net> <521C4CD9.4050308@freebsd.org> <0E0536B2-2B7F-4EED-9EFD-4B9E2C2D729A@freebsd.org> <521C87FF.8010100@freebsd.org> <521CB66B.9020806@freebsd.org> Content-Type: text/plain; charset="us-ascii" Date: Tue, 27 Aug 2013 08:57:35 -0600 Message-ID: <1377615455.1111.180.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Aug 2013 14:57:45 -0000 On Tue, 2013-08-27 at 16:23 +0200, Andre Oppermann wrote: > On 27.08.2013 15:29, Michael Tuexen wrote: > > On Aug 27, 2013, at 1:05 PM, Andre Oppermann wrote: > >> Thanks. I've changed the test accordingly. > >> > >> While doing the CTASSERTs to prevent such an incident in the future I stumbled > >> across a bit of evil name space pollution in mbuf.h. It is impossible to take > >> sizeof(struct m_ext) because "m_ext" is redefined to point into struct mbuf. > >> > >> In addition to the alignment fix I've solved the namespace issues with m_ext > >> and the stupidly named struct pkthdr as well and properly prefixed them. The > >> fallout from LINT was zero (as it should be). > >> > >> http://people.freebsd.org/~andre/m_hdr-alignment-20130827.diff > >> > >> Please test. > > > > Done. r254954 with your patch applied runs fine on a RPi. > > Does the CTASSERT trigger if the padding in m_hdr is not there? > Yes: --- uipc_mbuf.o --- /local/build/staging/freebsd/bb/src/sys/kern/uipc_mbuf.c:91:1: error: static_assert failed "compile-time assertion failed" CTASSERT(sizeof(struct mbuf) == MSIZE); Since the MLEN and MHLEN macros are used to size the data arrays based on the assumption that they begin at a given offset within the struct, these asserts more directly express that: CTASSERT(MSIZE - offsetof(struct mbuf, m_dat) == MLEN); CTASSERT(MSIZE - offsetof(struct mbuf, m_pktdat) == MHLEN); With these added you get all 3 asserts and somewhat more of a clue about why things are wrong (other than just sizeof mbuf being wrong): --- uipc_mbuf.o --- /local/build/staging/freebsd/bb/src/sys/kern/uipc_mbuf.c:91:1: error: static_assert failed "compile-time assertion failed" CTASSERT(sizeof(struct mbuf) == MSIZE); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ /local/build/staging/freebsd/bb/src/sys/sys/systm.h:100:21: note: expanded from macro 'CTASSERT' #define CTASSERT(x) _Static_assert(x, "compile-time assertion failed") ^ /local/build/staging/freebsd/bb/src/sys/kern/uipc_mbuf.c:97:1: error: static_assert failed "compile-time assertion failed" CTASSERT(MSIZE - offsetof(struct mbuf, m_dat) == MLEN); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ /local/build/staging/freebsd/bb/src/sys/sys/systm.h:100:21: note: expanded from macro 'CTASSERT' #define CTASSERT(x) _Static_assert(x, "compile-time assertion failed") ^ ~ /local/build/staging/freebsd/bb/src/sys/kern/uipc_mbuf.c:98:1: error: static_assert failed "compile-time assertion failed" CTASSERT(MSIZE - offsetof(struct mbuf, m_pktdat) == MHLEN); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ /local/build/staging/freebsd/bb/src/sys/sys/systm.h:100:21: note: expanded from macro 'CTASSERT' #define CTASSERT(x) _Static_assert(x, "compile-time assertion failed") ^ ~ IMO, it would be great if MLEN and MHLEN could be #define'd in terms of offsetof() expressions, but the compiler is unhappy about asking for offsetof an incomplete struct, even though it has all the info it needs at the point the expression is encountered. -- Ian From owner-freebsd-arm@FreeBSD.ORG Tue Aug 27 15:12:31 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 739E5A6D; Tue, 27 Aug 2013 15:12:31 +0000 (UTC) (envelope-from tuexen@freebsd.org) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 0696E2E57; Tue, 27 Aug 2013 15:12:31 +0000 (UTC) Received: from [192.168.1.200] (p508F3337.dip0.t-ipconnect.de [80.143.51.55]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 34F611C0C0695; Tue, 27 Aug 2013 17:12:29 +0200 (CEST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Subject: Re: ARM network trouble after recent mbuf changes From: Michael Tuexen In-Reply-To: <521CB66B.9020806@freebsd.org> Date: Tue, 27 Aug 2013 17:12:28 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <85F67DE2-701E-464B-8A9D-6A47C3B6C461@freebsd.org> References: <1377550636.1111.156.camel@revolution.hippie.lan> <521BC472.7040804@freebsd.org> <521BD531.4090104@sbcglobal.net> <521C4CD9.4050308@freebsd.org> <0E0536B2-2B7F-4EED-9EFD-4B9E2C2D729A@freebsd.org> <521C87FF.8010100@freebsd.org> <521CB66B.9020806@freebsd.org> To: Andre Oppermann 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: Tue, 27 Aug 2013 15:12:31 -0000 On Aug 27, 2013, at 4:23 PM, Andre Oppermann wrote: > On 27.08.2013 15:29, Michael Tuexen wrote: >> On Aug 27, 2013, at 1:05 PM, Andre Oppermann = wrote: >>> Thanks. I've changed the test accordingly. >>>=20 >>> While doing the CTASSERTs to prevent such an incident in the future = I stumbled >>> across a bit of evil name space pollution in mbuf.h. It is = impossible to take >>> sizeof(struct m_ext) because "m_ext" is redefined to point into = struct mbuf. >>>=20 >>> In addition to the alignment fix I've solved the namespace issues = with m_ext >>> and the stupidly named struct pkthdr as well and properly prefixed = them. The >>> fallout from LINT was zero (as it should be). >>>=20 >>> http://people.freebsd.org/~andre/m_hdr-alignment-20130827.diff >>>=20 >>> Please test. > > >> Done. r254954 with your patch applied runs fine on a RPi. >=20 > Does the CTASSERT trigger if the padding in m_hdr is not there? Yepp: /usr/home/tuexen/head/sys/kern/uipc_mbuf.c:91:1: error: static_assert = failed "compile-time assertion failed" CTASSERT(sizeof(struct mbuf) =3D=3D MSIZE); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ /usr/home/tuexen/head/sys/sys/systm.h:100:21: note: expanded from macro = 'CTASSERT' #define CTASSERT(x) _Static_assert(x, "compile-time assertion = failed") ^ ~ 1 error generated. Best regards Michael >=20 > --=20 > Andre >=20 >=20 From owner-freebsd-arm@FreeBSD.ORG Tue Aug 27 15:41: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 250876B4; Tue, 27 Aug 2013 15:41:04 +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 069F32024; Tue, 27 Aug 2013 15:41:03 +0000 (UTC) Received: from bender (global-1-18.nat.csx.cam.ac.uk [131.111.184.18]) by nibbler.fubar.geek.nz (Postfix) with ESMTPSA id 0D4005DFF7; Tue, 27 Aug 2013 15:41:01 +0000 (UTC) Date: Tue, 27 Aug 2013 16:40:55 +0100 From: Andrew Turner To: Warner Losh Subject: Re: ARM network trouble after recent mbuf changes Message-ID: <20130827164055.4a757a13@bender> In-Reply-To: References: <1377550636.1111.156.camel@revolution.hippie.lan> <521BC472.7040804@freebsd.org> <521BD531.4090104@sbcglobal.net> <521C4CD9.4050308@freebsd.org> <20130827102810.37e2dfc7@bender> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-arm , Andre Oppermann 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, 27 Aug 2013 15:41:04 -0000 On Tue, 27 Aug 2013 07:26:03 -0600 Warner Losh wrote: > > On Aug 27, 2013, at 3:28 AM, Andrew Turner wrote: > > > On Tue, 27 Aug 2013 08:53:13 +0200 > > Andre Oppermann wrote: > >> Please try the patch below to confirm. If it fixes your problem > >> for now I'm going to commit as an immediate fix while searching > >> for a better long term stable solution. > >> > > > > I tried this with a CTASSERT to check if struct m_hdr is the correct > > length. In this test the size is incorrect. It appears __ILP32__ is > > not defined on ARM. > > > > I have tested a fix suggested by Hans Petter Selasky where we mark > > m_hdr with __aligned(8). With this change I can netboot a > > PandaBoard. > > Isn't that a bug with our arm compiler then? No, on ARM EABI the definition of the size of a struct is to be the smallest multiple of its alignment. As we are increasing the alignment to 8-byte and the struct without this alignment is not a multiple of 8-bytes adding this alignment will pad to struct to use the unused 4 bytes between this and the next struct. Andrew > > Warner > > From owner-freebsd-arm@FreeBSD.ORG Tue Aug 27 15:56:36 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 3F44AAB2 for ; Tue, 27 Aug 2013 15:56:36 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-gh0-f169.google.com (mail-gh0-f169.google.com [209.85.160.169]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 000A1211E for ; Tue, 27 Aug 2013 15:56:35 +0000 (UTC) Received: by mail-gh0-f169.google.com with SMTP id r1so1239642ghr.14 for ; Tue, 27 Aug 2013 08:56:28 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; 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=xkfrt6nr7SQZK0GzpZPWPIoK0gSy72Ji3Szg/7T2ASw=; b=YpacrRxgJLBYrGgQaqGH/xK0fAZXZ2Aob1mXxzz616O74NsLKUGcmVvtwSCU9JKNQT ZVsNYxsKeND+ceyRwRB5/bl+v9TENH/WwODBvmdFVQKRf6lSt4FtJZkWxYa9MHm+w+O3 1lisQgJ2m0ZRo0YqozKPDe/dIr/U5qN6GTwVAAR+PVylC5//8v1CLIzCH/OaiNUKMrDB RmRuYWvQp1PNltnwTm17BL5L4U1oeJPFFSC39+a7K1lMxw6M9X7C0Cv1VEiWGAeORDGs gczVpwk2PvckeTlV6exl4PNpJPkq45bZ5hE89+r/wumvOpujuW4mrl2aqzO6fF7B+Ihn bh5g== X-Gm-Message-State: ALoCoQnzK2J+4K7SJ9ZhLSmnSZn1G4UzHzgPkoqjYeDIw1fpgEOLRH09qbtB7EELp0TiqZdlFYGj X-Received: by 10.236.156.5 with SMTP id l5mr20704195yhk.5.1377618988824; Tue, 27 Aug 2013 08:56:28 -0700 (PDT) Received: from monkey-bot.int.fusionio.com ([209.117.142.2]) by mx.google.com with ESMTPSA id c7sm25053454yhk.23.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 27 Aug 2013 08:56:25 -0700 (PDT) Sender: Warner Losh Subject: Re: ARM network trouble after recent mbuf changes Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <20130827164055.4a757a13@bender> Date: Tue, 27 Aug 2013 09:56:20 -0600 Content-Transfer-Encoding: 7bit Message-Id: References: <1377550636.1111.156.camel@revolution.hippie.lan> <521BC472.7040804@freebsd.org> <521BD531.4090104@sbcglobal.net> <521C4CD9.4050308@freebsd.org> <20130827102810.37e2dfc7@bender> <20130827164055.4a757a13@bender> To: Andrew Turner X-Mailer: Apple Mail (2.1085) Cc: freebsd-arm , Andre Oppermann 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, 27 Aug 2013 15:56:36 -0000 On Aug 27, 2013, at 9:40 AM, Andrew Turner wrote: > On Tue, 27 Aug 2013 07:26:03 -0600 > Warner Losh wrote: > >> >> On Aug 27, 2013, at 3:28 AM, Andrew Turner wrote: >> >>> On Tue, 27 Aug 2013 08:53:13 +0200 >>> Andre Oppermann wrote: >>>> Please try the patch below to confirm. If it fixes your problem >>>> for now I'm going to commit as an immediate fix while searching >>>> for a better long term stable solution. >>>> >>> >>> I tried this with a CTASSERT to check if struct m_hdr is the correct >>> length. In this test the size is incorrect. It appears __ILP32__ is >>> not defined on ARM. >>> >>> I have tested a fix suggested by Hans Petter Selasky where we mark >>> m_hdr with __aligned(8). With this change I can netboot a >>> PandaBoard. >> >> Isn't that a bug with our arm compiler then? > > No, on ARM EABI the definition of the size of a struct is to be the > smallest multiple of its alignment. As we are increasing the alignment > to 8-byte and the struct without this alignment is not a multiple of > 8-bytes adding this alignment will pad to struct to use the unused 4 > bytes between this and the next struct. Wrong bug :) Is it not a bug that __ILP32__ is undefined? Warner > Andrew >> >> Warner >> >> > From owner-freebsd-arm@FreeBSD.ORG Tue Aug 27 15:59: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 3FCCEB2B; Tue, 27 Aug 2013 15:59:18 +0000 (UTC) (envelope-from tuexen@freebsd.org) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id C3C092135; Tue, 27 Aug 2013 15:59:17 +0000 (UTC) Received: from [192.168.1.200] (p508F3337.dip0.t-ipconnect.de [80.143.51.55]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id EF1DC1C0C0692; Tue, 27 Aug 2013 17:59:15 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Subject: Re: ARM network trouble after recent mbuf changes From: Michael Tuexen In-Reply-To: Date: Tue, 27 Aug 2013 17:59:14 +0200 Content-Transfer-Encoding: 7bit Message-Id: <76A89374-49EB-4902-A92F-6B44DADFCF8D@freebsd.org> References: <1377550636.1111.156.camel@revolution.hippie.lan> <521BC472.7040804@freebsd.org> <521BD531.4090104@sbcglobal.net> <521C4CD9.4050308@freebsd.org> <20130827102810.37e2dfc7@bender> <20130827164055.4a757a13@bender> To: Warner Losh X-Mailer: Apple Mail (2.1508) Cc: freebsd-arm , Andre Oppermann 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, 27 Aug 2013 15:59:18 -0000 On Aug 27, 2013, at 5:56 PM, Warner Losh wrote: > > On Aug 27, 2013, at 9:40 AM, Andrew Turner wrote: > >> On Tue, 27 Aug 2013 07:26:03 -0600 >> Warner Losh wrote: >> >>> >>> On Aug 27, 2013, at 3:28 AM, Andrew Turner wrote: >>> >>>> On Tue, 27 Aug 2013 08:53:13 +0200 >>>> Andre Oppermann wrote: >>>>> Please try the patch below to confirm. If it fixes your problem >>>>> for now I'm going to commit as an immediate fix while searching >>>>> for a better long term stable solution. >>>>> >>>> >>>> I tried this with a CTASSERT to check if struct m_hdr is the correct >>>> length. In this test the size is incorrect. It appears __ILP32__ is >>>> not defined on ARM. >>>> >>>> I have tested a fix suggested by Hans Petter Selasky where we mark >>>> m_hdr with __aligned(8). With this change I can netboot a >>>> PandaBoard. >>> >>> Isn't that a bug with our arm compiler then? >> >> No, on ARM EABI the definition of the size of a struct is to be the >> smallest multiple of its alignment. As we are increasing the alignment >> to 8-byte and the struct without this alignment is not a multiple of >> 8-bytes adding this alignment will pad to struct to use the unused 4 >> bytes between this and the next struct. > > Wrong bug :) > > Is it not a bug that __ILP32__ is undefined? Is it used anywhere? I only found __LP64__ being used... Best regards Michael > > Warner > >> Andrew >>> >>> Warner >>> >>> >> > > _______________________________________________ > 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 Aug 27 17:14:26 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 1B6195E2 for ; Tue, 27 Aug 2013 17:14:26 +0000 (UTC) (envelope-from ThomasSkibo@sbcglobal.net) Received: from nm5-vm5.access.bullet.mail.gq1.yahoo.com (nm5-vm5.access.bullet.mail.gq1.yahoo.com [216.39.63.123]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id B458825C9 for ; Tue, 27 Aug 2013 17:14:25 +0000 (UTC) Received: from [216.39.60.175] by nm5.access.bullet.mail.gq1.yahoo.com with NNFMP; 27 Aug 2013 17:08:19 -0000 Received: from [67.195.15.63] by tm11.access.bullet.mail.gq1.yahoo.com with NNFMP; 27 Aug 2013 17:08:19 -0000 Received: from [127.0.0.1] by smtp104.sbc.mail.gq1.yahoo.com with NNFMP; 27 Aug 2013 17:08:19 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sbcglobal.net; s=s1024; t=1377623299; bh=kh+7PBu8ZxK72E/BFjpNw2kfXoZ96B7xD8bmtRWlDFk=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=lLput/9HkcLXEAkQf+tgR0HT78Yv9NgvgJz1ylYl6SDAwOJs97lq825Rx4hyWBQ6LXq1PFU30s8GKqS6oW4mGXz2QU0TIPQdISl4l+2xzPbM2wmS7oClVpP5YvOsBgj2k1Gti2aWVjWMsnXj81lN+0H8zlRz5+MNfq6Z/rota9k= X-Yahoo-Newman-Id: 582110.3786.bm@smtp104.sbc.mail.gq1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: M0YfUmIVM1mdNB8JlqkpW_WEvx8gwTOEgs4PO5XMCBsPeVD 2qaCvI.37q3x6ePLQlGbQBj7pIGjKU1KC7GHlm2Xa3rJSonHhbRL0ckeMytj fJ24d357TT3jUkEa6VOlIl5Z8JLxC6ROrGqmgVPx7HZWgadAH.p9pH2O_8k. Ta0rakkYOBYapLGnZfbFGQWUUUOV86uHtkkWP.khAeaW8mwbgE7NYVYQs9ud d8qM4_YmiK6Da7ORhssOUrD3LdXVoH58FFoUnyItA3cxO4z7AHPrL5FhXWTe seHEiZNP0.bsjxtk5lggW38OgolaOWzYW3IkmBZzRJDoTSeKxkIbP7ZIu2B4 gLbijytc6w3D2sQfGYrlwTYdLyyXq1EP.Bm5M81L2mA3baxpOugyaKYojtJv 80N6bUxA22wB6IlTPjAr5qFxkNZ8FbLCl0M383GULzNO6JzdX.Mxuvrp3AzV DOhqt_Go8DspXHa6VY85YcCD6Y.7QjT.VdDZPkBonWGz2Vd6_99g1OI5HdDu gXDR5hTffE3VG403N7ijrsG9Y3PaStbkNadLMwwYJ86rRGaSrTf67KrEv9gD m4iWcWLn3Yty7FSxgMOJwEVecXGAyf3hQ3Wx0wnsZ1hHguFI4RZVEhYcsH7Z 3xHZ5GzNfVOQSTcQMPOejRKMlHLk5t3tg_OlIzxLaqSczjOld_WWQo.EqJd8 21KwslA.N_2iDy33U X-Yahoo-SMTP: tUxoRneswBA21azLM.3ybMESf0mC2bFhTbmt0VU5ervH0kqi5lo- X-Rocket-Received: from [192.168.1.9] (ThomasSkibo@71.139.173.243 with plain) by smtp104.sbc.mail.gq1.yahoo.com with SMTP; 27 Aug 2013 10:08:19 -0700 PDT Message-ID: <521CDD03.1010108@sbcglobal.net> Date: Tue, 27 Aug 2013 10:08:19 -0700 From: Thomas Skibo 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: Andre Oppermann Subject: Re: ARM network trouble after recent mbuf changes References: <1377550636.1111.156.camel@revolution.hippie.lan> <521BC472.7040804@freebsd.org> <521BD531.4090104@sbcglobal.net> <521C4CD9.4050308@freebsd.org> <0E0536B2-2B7F-4EED-9EFD-4B9E2C2D729A@freebsd.org> <521C87FF.8010100@freebsd.org> In-Reply-To: <521C87FF.8010100@freebsd.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Aug 2013 17:14:26 -0000 On 8/27/13 4:05 AM, Andre Oppermann wrote: > > Thanks. I've changed the test accordingly. > > While doing the CTASSERTs to prevent such an incident in the future I > stumbled > across a bit of evil name space pollution in mbuf.h. It is impossible > to take > sizeof(struct m_ext) because "m_ext" is redefined to point into struct > mbuf. > > In addition to the alignment fix I've solved the namespace issues with > m_ext > and the stupidly named struct pkthdr as well and properly prefixed > them. The > fallout from LINT was zero (as it should be). > > http://people.freebsd.org/~andre/m_hdr-alignment-20130827.diff > > Please test. > I'm running this patch on Zedboard and it is doing well. Thanks! -- -------- Thomas Skibo ThomasSkibo@sbcglobal.net From owner-freebsd-arm@FreeBSD.ORG Tue Aug 27 17:18:54 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 23081887 for ; Tue, 27 Aug 2013 17:18:54 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-yh0-f43.google.com (mail-yh0-f43.google.com [209.85.213.43]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id D677125FC for ; Tue, 27 Aug 2013 17:18:53 +0000 (UTC) Received: by mail-yh0-f43.google.com with SMTP id z20so1293870yhz.2 for ; Tue, 27 Aug 2013 10:18:47 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; 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=3A+R/xX2V0FkyqAfBBBcPj2CDmknCwnlUJxjyOoVuQ4=; b=fK9kLPqu2XfDWsqkyGWXOagKXZreOzapdhaQPXrCFOfSwmXibTzQxMq5IOa6ongY5J lNfVTVzEVDIKnTalBCCvWzhHGgco5HbX0WOfIUNY0NuQnYlITYINgxkOpYJ+XvFpAxSQ dVr0j2fgT88b0kMfZBo4JbUM9fcTJSGRJNEuLVywLdqWAhmOdme0cdEaRJ1K/dRrs70L 6nrBMrsNQXb+cNXxO520bBRs86LaLaleOW0k7GcwqrQ9XpOnhc0OqsePemuH5iVarkhm o3WyoBd4tB0Edsm+TqdPnRWxKAzyUgNo5CF0l+BeWINAxUDdyhwwMtnXDRYjAvadY4yp katA== X-Gm-Message-State: ALoCoQmEg5lB2da9y7K8oLdvO7tGxOGpB8n0Dl5rkxMIktaBOZbqseg5Dl7qQ8LITlb0a5pJj+Dy X-Received: by 10.236.50.135 with SMTP id z7mr1267172yhb.110.1377622175756; Tue, 27 Aug 2013 09:49:35 -0700 (PDT) Received: from monkey-bot.int.fusionio.com ([209.117.142.2]) by mx.google.com with ESMTPSA id i28sm25400155yhl.2.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 27 Aug 2013 09:49:33 -0700 (PDT) Sender: Warner Losh Subject: Re: ARM network trouble after recent mbuf changes Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <76A89374-49EB-4902-A92F-6B44DADFCF8D@freebsd.org> Date: Tue, 27 Aug 2013 10:49:29 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <7E1F1106-654B-4AEC-B915-F97D95C24E75@bsdimp.com> References: <1377550636.1111.156.camel@revolution.hippie.lan> <521BC472.7040804@freebsd.org> <521BD531.4090104@sbcglobal.net> <521C4CD9.4050308@freebsd.org> <20130827102810.37e2dfc7@bender> <20130827164055.4a757a13@bender> <76A89374-49EB-4902-A92F-6B44DADFCF8D@freebsd.org> To: Michael Tuexen X-Mailer: Apple Mail (2.1085) Cc: freebsd-arm , Andre Oppermann 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, 27 Aug 2013 17:18:54 -0000 On Aug 27, 2013, at 9:59 AM, Michael Tuexen wrote: > On Aug 27, 2013, at 5:56 PM, Warner Losh wrote: >=20 >>=20 >> On Aug 27, 2013, at 9:40 AM, Andrew Turner wrote: >>=20 >>> On Tue, 27 Aug 2013 07:26:03 -0600 >>> Warner Losh wrote: >>>=20 >>>>=20 >>>> On Aug 27, 2013, at 3:28 AM, Andrew Turner wrote: >>>>=20 >>>>> On Tue, 27 Aug 2013 08:53:13 +0200 >>>>> Andre Oppermann wrote: >>>>>> Please try the patch below to confirm. If it fixes your problem >>>>>> for now I'm going to commit as an immediate fix while searching >>>>>> for a better long term stable solution. >>>>>>=20 >>>>>=20 >>>>> I tried this with a CTASSERT to check if struct m_hdr is the = correct >>>>> length. In this test the size is incorrect. It appears __ILP32__ = is >>>>> not defined on ARM. >>>>>=20 >>>>> I have tested a fix suggested by Hans Petter Selasky where we mark >>>>> m_hdr with __aligned(8). With this change I can netboot a >>>>> PandaBoard. >>>>=20 >>>> Isn't that a bug with our arm compiler then? >>>=20 >>> No, on ARM EABI the definition of the size of a struct is to be the >>> smallest multiple of its alignment. As we are increasing the = alignment >>> to 8-byte and the struct without this alignment is not a multiple of >>> 8-bytes adding this alignment will pad to struct to use the unused 4 >>> bytes between this and the next struct. >>=20 >> Wrong bug :) >>=20 >> Is it not a bug that __ILP32__ is undefined? > Is it used anywhere? I only found __LP64__ being used... _ILP32 is used in code we got from Solaris. Otherwise, you're right: we = don't use it in the tree. Lots of places use __LP64__ though. Warner= From owner-freebsd-arm@FreeBSD.ORG Tue Aug 27 20:51: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 C64CB503 for ; Tue, 27 Aug 2013 20:51:40 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 330742196 for ; Tue, 27 Aug 2013 20:51:39 +0000 (UTC) Received: (qmail 15651 invoked from network); 27 Aug 2013 21:33:36 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 27 Aug 2013 21:33:36 -0000 Message-ID: <521D1156.9030708@freebsd.org> Date: Tue, 27 Aug 2013 22:51:34 +0200 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Ian Lepore Subject: Re: ARM network trouble after recent mbuf changes References: <1377550636.1111.156.camel@revolution.hippie.lan> <521BC472.7040804@freebsd.org> <521BD531.4090104@sbcglobal.net> <521C4CD9.4050308@freebsd.org> <0E0536B2-2B7F-4EED-9EFD-4B9E2C2D729A@freebsd.org> <521C87FF.8010100@freebsd.org> <521CB66B.9020806@freebsd.org> <1377615455.1111.180.camel@revolution.hippie.lan> In-Reply-To: <1377615455.1111.180.camel@revolution.hippie.lan> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Aug 2013 20:51:40 -0000 On 27.08.2013 16:57, Ian Lepore wrote: > On Tue, 2013-08-27 at 16:23 +0200, Andre Oppermann wrote: >> On 27.08.2013 15:29, Michael Tuexen wrote: >>> On Aug 27, 2013, at 1:05 PM, Andre Oppermann wrote: >>>> Thanks. I've changed the test accordingly. >>>> >>>> While doing the CTASSERTs to prevent such an incident in the future I stumbled >>>> across a bit of evil name space pollution in mbuf.h. It is impossible to take >>>> sizeof(struct m_ext) because "m_ext" is redefined to point into struct mbuf. >>>> >>>> In addition to the alignment fix I've solved the namespace issues with m_ext >>>> and the stupidly named struct pkthdr as well and properly prefixed them. The >>>> fallout from LINT was zero (as it should be). >>>> >>>> http://people.freebsd.org/~andre/m_hdr-alignment-20130827.diff >>>> >>>> Please test. >> > >>> Done. r254954 with your patch applied runs fine on a RPi. >> >> Does the CTASSERT trigger if the padding in m_hdr is not there? >> > > Yes: > > --- uipc_mbuf.o --- > /local/build/staging/freebsd/bb/src/sys/kern/uipc_mbuf.c:91:1: error: static_assert failed "compile-time assertion failed" > CTASSERT(sizeof(struct mbuf) == MSIZE); > > > Since the MLEN and MHLEN macros are used to size the data arrays based > on the assumption that they begin at a given offset within the struct, > these asserts more directly express that: > > CTASSERT(MSIZE - offsetof(struct mbuf, m_dat) == MLEN); > CTASSERT(MSIZE - offsetof(struct mbuf, m_pktdat) == MHLEN); > > With these added you get all 3 asserts and somewhat more of a clue about > why things are wrong (other than just sizeof mbuf being wrong): Excellent. I exchanged them for the struct mbuf member asserts. > --- uipc_mbuf.o --- > /local/build/staging/freebsd/bb/src/sys/kern/uipc_mbuf.c:91:1: error: static_assert failed "compile-time assertion failed" > CTASSERT(sizeof(struct mbuf) == MSIZE); > ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > /local/build/staging/freebsd/bb/src/sys/sys/systm.h:100:21: note: expanded from macro 'CTASSERT' > #define CTASSERT(x) _Static_assert(x, "compile-time assertion failed") > ^ > /local/build/staging/freebsd/bb/src/sys/kern/uipc_mbuf.c:97:1: error: static_assert failed "compile-time assertion failed" > CTASSERT(MSIZE - offsetof(struct mbuf, m_dat) == MLEN); > ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > /local/build/staging/freebsd/bb/src/sys/sys/systm.h:100:21: note: expanded from macro 'CTASSERT' > #define CTASSERT(x) _Static_assert(x, "compile-time assertion failed") > ^ ~ > /local/build/staging/freebsd/bb/src/sys/kern/uipc_mbuf.c:98:1: error: static_assert failed "compile-time assertion failed" > CTASSERT(MSIZE - offsetof(struct mbuf, m_pktdat) == MHLEN); > ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > /local/build/staging/freebsd/bb/src/sys/sys/systm.h:100:21: note: expanded from macro 'CTASSERT' > #define CTASSERT(x) _Static_assert(x, "compile-time assertion failed") > ^ ~ > > > IMO, it would be great if MLEN and MHLEN could be #define'd in terms of > offsetof() expressions, but the compiler is unhappy about asking for > offsetof an incomplete struct, even though it has all the info it needs > at the point the expression is encountered. Yeah, I couldn't find a way either to solve this nasty circular dependency. -- Andre From owner-freebsd-arm@FreeBSD.ORG Tue Aug 27 20:54: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 785846AF for ; Tue, 27 Aug 2013 20:54:33 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id DB68921B4 for ; Tue, 27 Aug 2013 20:54:32 +0000 (UTC) Received: (qmail 15677 invoked from network); 27 Aug 2013 21:36:30 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 27 Aug 2013 21:36:30 -0000 Message-ID: <521D1203.6070506@freebsd.org> Date: Tue, 27 Aug 2013 22:54:27 +0200 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Thomas Skibo Subject: Re: ARM network trouble after recent mbuf changes References: <1377550636.1111.156.camel@revolution.hippie.lan> <521BC472.7040804@freebsd.org> <521BD531.4090104@sbcglobal.net> <521C4CD9.4050308@freebsd.org> <0E0536B2-2B7F-4EED-9EFD-4B9E2C2D729A@freebsd.org> <521C87FF.8010100@freebsd.org> <521CDD03.1010108@sbcglobal.net> In-Reply-To: <521CDD03.1010108@sbcglobal.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Aug 2013 20:54:33 -0000 On 27.08.2013 19:08, Thomas Skibo wrote: > > > On 8/27/13 4:05 AM, Andre Oppermann wrote: >> >> Thanks. I've changed the test accordingly. >> >> While doing the CTASSERTs to prevent such an incident in the future I >> stumbled >> across a bit of evil name space pollution in mbuf.h. It is impossible >> to take >> sizeof(struct m_ext) because "m_ext" is redefined to point into struct >> mbuf. >> >> In addition to the alignment fix I've solved the namespace issues with >> m_ext >> and the stupidly named struct pkthdr as well and properly prefixed >> them. The >> fallout from LINT was zero (as it should be). >> >> http://people.freebsd.org/~andre/m_hdr-alignment-20130827.diff >> >> Please test. >> > > I'm running this patch on Zedboard and it is doing well. Thanks! Fix is in with r254973 (sans the structure renamings to avoid name space clashes). Sorry for the trouble and thanks for your help with debugging and testing. -- Andre From owner-freebsd-arm@FreeBSD.ORG Wed Aug 28 00: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 3FCBDF38; Wed, 28 Aug 2013 00:02:29 +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 E8A422CF8; Wed, 28 Aug 2013 00:02:28 +0000 (UTC) Received: from wonderland.m5p.com (localhost [IPv6:::1]) by mailhost.m5p.com (8.14.5/8.14.5) with ESMTP id r7S02Kcf003662; Tue, 27 Aug 2013 20:02:25 -0400 (EDT) (envelope-from george+freebsd@m5p.com) Message-ID: <521D3E0C.4060507@m5p.com> Date: Tue, 27 Aug 2013 20:02: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: Hans Petter Selasky Subject: Re: ulpt can't attach Lexmark E120 References: <5105527F.3010708@m5p.com> <201301271915.47712.hselasky@c2i.net> <510570C1.1060607@m5p.com> <201301272007.30682.hselasky@c2i.net> <5105AB16.2000607@m5p.com> <5215F4DF.6000305@m5p.com> <5215F743.8060403@bitfrost.no> <5216ACE5.7000500@m5p.com> <5216FE9F.2030608@bitfrost.no> <52174378.2020101@m5p.com> <521801E5.9000309@m5p.com> <52184F59.5080100@bitfrost.no> <5218F993.9050504@m5p.com> <5219C3FF.1070509@bitfrost.no> In-Reply-To: <5219C3FF.1070509@bitfrost.no> 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, 27 Aug 2013 20:02:25 -0400 (EDT) Cc: freebsd-arm@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: Wed, 28 Aug 2013 00:02:29 -0000 On 08/25/13 04:44, Hans Petter Selasky wrote: > On 08/24/13 20:21, George Mitchell wrote: >> >> Setting hw.usb.dwc_otg.debug to any value greater than 0 generates an >> unending stream of debug output and effectively locks up the chip >> scrolling the output on the display. Perhaps there are some specific >> debug messages I could put in ... -- George > > Hi, > > Can you try this patch: > > http://svnweb.freebsd.org/changeset/base/254828 > > --HPS > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" Sorry, no more progress yet. My RPi build system is generating emptyimages for some reason, so I will start over with it. -- George From owner-freebsd-arm@FreeBSD.ORG Wed Aug 28 05:40:01 2013 Return-Path: Delivered-To: freebsd-arm@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 4298C4BA for ; Wed, 28 Aug 2013 05:40:01 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 088192B73 for ; Wed, 28 Aug 2013 05:40:01 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r7S5e0MV098364 for ; Wed, 28 Aug 2013 05:40:00 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r7S5e05m098363; Wed, 28 Aug 2013 05:40:00 GMT (envelope-from gnats) Resent-Date: Wed, 28 Aug 2013 05:40:00 GMT Resent-Message-Id: <201308280540.r7S5e05m098363@freefall.freebsd.org> Resent-From: FreeBSD-gnats-submit@FreeBSD.org (GNATS Filer) Resent-To: freebsd-arm@FreeBSD.org Resent-Reply-To: FreeBSD-gnats-submit@FreeBSD.org, Martin Laabs 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 5768B443 for ; Wed, 28 Aug 2013 05:35:56 +0000 (UTC) (envelope-from nobody@FreeBSD.org) Received: from oldred.freebsd.org (oldred.freebsd.org [8.8.178.121]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 34B9E2B5E for ; Wed, 28 Aug 2013 05:35:56 +0000 (UTC) Received: from oldred.freebsd.org ([127.0.1.6]) by oldred.freebsd.org (8.14.5/8.14.7) with ESMTP id r7S5ZuHF060148 for ; Wed, 28 Aug 2013 05:35:56 GMT (envelope-from nobody@oldred.freebsd.org) Received: (from nobody@localhost) by oldred.freebsd.org (8.14.5/8.14.5/Submit) id r7S5Zudp060143; Wed, 28 Aug 2013 05:35:56 GMT (envelope-from nobody) Message-Id: <201308280535.r7S5Zudp060143@oldred.freebsd.org> Date: Wed, 28 Aug 2013 05:35:56 GMT From: Martin Laabs To: freebsd-gnats-submit@FreeBSD.org X-Send-Pr-Version: www-3.1 Subject: arm/181601: Sporadic failure of root mount on ARM/Raspberry 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, 28 Aug 2013 05:40:01 -0000 >Number: 181601 >Category: arm >Synopsis: Sporadic failure of root mount on ARM/Raspberry >Confidential: no >Severity: non-critical >Priority: low >Responsible: freebsd-arm >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Wed Aug 28 05:40:00 UTC 2013 >Closed-Date: >Last-Modified: >Originator: Martin Laabs >Release: FreeBSD 10.0-CURRENT #0 r254955M >Organization: - >Environment: not available >Description: Sporadicly the raspberry pi failes to mount its root mmc card. After power off and power on again works most of the time. However there seem to be also configurations that fail permanently. Unfortunately I have no image of a sd card that fails on every boot. The full boot log output is attached to this bug report. Trying to mount root from ufs:/dev/mmcsd0s2a [rw,noatime]... mountroot: waiting for device /dev/mmcsd0s2a ... smsc0: chip 0xec00, rev. 0002 miibus0: on smsc0 ukphy0: PHY 1 on miibus0 ukphy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto ue0: on smsc0 ue0: Ethernet address: b8:27:eb:1d:b7:5a Mounting from ufs:/dev/mmcsd0s2a failed with error 19. Loader variables: vfs.root.mountfrom=ufs:/dev/mmcsd0s2a vfs.root.mountfrom.options=rw,noatime Manual root filesystem specification: : [options] Mount using filesystem and with the specified (optional) option list. eg. ufs:/dev/da0s1a zfs:tank cd9660:/dev/acd0 ro (which is equivalent to: mount -t cd9660 -o ro /dev/acd0 /) ? List valid disk boot devices . Yield 1 second (for background tasks) Abort manual input mountroot> >How-To-Repeat: Boot the Raspberry Pi several times and look if >Fix: Patch attached with submission follows: U-Boot 2013.01-rc1-g6709570-dirty (Aug 17 2013 - 23:35:05) DRAM: 480 MiB WARNING: Caches not enabled MMC: bcm2835_sdhci: 0 Using default environment In: serial Out: lcd Err: lcd mbox: Timeout waiting for response bcm2835: Could not set USB power state Net: Net Initialization Skipped No ethernet found. Hit any key to stop autoboot: 3  2  1  0 reading uEnv.txt 89 bytes read in 9541 ms (0 Bytes/s) Importing environment from mmc ... reading ubldr 239540 bytes read in 54396 ms (3.9 KiB/s) ## Starting application at 0x02000054 ... Consoles: U-Boot console Compatible API signature found @1db682a8 Number of U-Boot devices: 1 FreeBSD/armv6 U-Boot loader, Revision 1.2 (martin@pcbsd-7130, Wed Aug 28 01:32:51 CEST 2013) DRAM: 480MB Device: disk |/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|Loading /boot/defaults/loader.conf /-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\/boot/kernel/kernel data=0x47b5e4+0x17e19c |/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|syms=[0x4+0x7fcb0/-\|/-\|/-\|/-\|+0x4+0x4d613/-\|/-\|/-] Hit [Enter] to boot immediately, or any other key for command prompt. Booting [/boot/kernel/kernel]... \|/-\|/Using DTB provided by U-Boot. Kernel entry at 0x100100... Kernel args: (null) 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-CURRENT #0 r254955M: Wed Aug 28 01:32:36 CEST 2013 martin@pcbsd-7130:/usr/home/martin/Rasperry/crochet-freebsd/work/obj/arm.armv6/usr/home/martin/Rasperry/head/sys/RPI-B arm FreeBSD clang version 3.3 (tags/RELEASE_33/final 183502) 20130610 WARNING: WITNESS option enabled, expect reduced performance. WARNING: DIAGNOSTIC option enabled, expect reduced performance. CPU: 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 = 536870912 (512 MB) avail memory = 482902016 (460 MB) random device not loaded; using insecure entropy 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 bcm_dma0: mem 0x20007000-0x20007fff,0x20e05000-0x20e05fff irq 24,25,26,27,28,29,30,31,32,33,34,35,36 on simplebus0 mbox0: mem 0x2000b880-0x2000b8bf irq 1 on simplebus0 sdhci_bcm0: mem 0x20300000-0x203000ff irq 70 on simplebus0 mmc0: on sdhci_bcm0 uart0: mem 0x20201000-0x20201fff irq 65 on simplebus0 uart0: console (115200,n,8,1) dwcotg0: mem 0x20980000-0x2099ffff irq 17 on simplebus0 usbus0 on dwcotg0 simplebus1: on fdtbus0 Timecounters tick every 10.000 msec lock order reversal: 1st 0xc06f3c0c entropy harvest mutex (entropy harvest mutex) @ /usr/home/martin/Rasperry/head/sys/dev/random/randomdev_soft.c:242 2nd 0xc25d7c20 uart_hwmtx (uart_hwmtx) @ /usr/home/martin/Rasperry/head/sys/dev/uart/uart_cpu.h:92 KDB: stack backtrace: db_trace_self() at db_trace_self pc = 0xc04652cc lr = 0xc012e474 (db_trace_self_wrapper+0x30) sp = 0xdc20c9c8 fp = 0xdc20cae0 r10 = 0xc06f3c0c db_trace_self_wrapper() at db_trace_self_wrapper+0x30 pc = 0xc012e474 lr = 0xc0268974 (kdb_backtrace+0x38) sp = 0xdc20cae8 fp = 0xdc20caf0 r4 = 0xc05908a4 r5 = 0xc049fb59 r6 = 0xc04bd04d r7 = 0xc049f1d4 kdb_backtrace() at kdb_backtrace+0x38 pc = 0xc0268974 lr = 0xc0282df8 (witness_checkorder+0xddc) sp = 0xdc20caf8 fp = 0xdc20cb48 r4 = 0xc049fa8a witness_checkorder() at witness_checkorder+0xddc pc = 0xc0282df8 lr = 0xc022050c (__mtx_lock_spin_flags+0xc4) sp = 0xdc20cb50 fp = 0xdc20cb70 r4 = 0x00000000 r5 = 0xc0580a84 r6 = 0xc25d7c20 r7 = 0xc25d7c30 r8 = 0x00000000 r9 = 0x0000005c r10 = 0xc049fb56 __mtx_lock_spin_flags() at __mtx_lock_spin_flags+0xc4 pc = 0xc022050c lr = 0xc014e9a4 (uart_cnputc+0x44) sp = 0xdc20cb78 fp = 0xdc20cb88 r4 = 0x0000006c r5 = 0xc0580a84 r6 = 0xc05908a0 r7 = 0xc0581700 r8 = 0xc055d590 r9 = 0xc05816e0 r10 = 0xdc20ccf0 uart_cnputc() at uart_cnputc+0x44 pc = 0xc014e9a4 lr = 0xc01eb6b0 (cnputc+0x80) sp = 0xdc20cb90 fp = 0xdc20cba8 r4 = 0x0000006c r5 = 0xc0551c30 r6 = 0xc05908a0 cnputc() at cnputc+0x80 pc = 0xc01eb6b0 lr = 0xc026e6ec (putchar+0x194) sp = 0xdc20cbb0 fp = 0xdc20cc18 r4 = 0x00000005 r5 = 0xdc20ccf0 r6 = 0x0000006c r7 = 0x00000000 r8 = 0xc06f52b4 r9 = 0xc026e558 putchar() at putchar+0x194 pc = 0xc026e6ec lr = 0xc026d53c (kvprintf+0xb0) sp = 0xdc20cc20 fp = 0xdc20ccd8 r4 = 0xc04bc4c4 r5 = 0x00000000 r6 = 0x00000000 r7 = 0x00000000 r8 = 0xc06f52b4 r9 = 0xc026e558 r10 = 0xdc20ccf0 kvprintf() at kvprintf+0xb0 pc = 0xc026d53c lr = 0xc026ec58 (printf+0x50) sp = 0xdc20cce0 fp = 0xdc20cd10 r4 = 0xc2446da8 r5 = 0xc2446a68 r6 = 0x00000000 r7 = 0xc06c394c r8 = 0xc06f52b4 r9 = 0x00000001 r10 = 0xc06c395b printf() at printf+0x50 pc = 0xc026ec58 lr = 0xc0282b58 (witness_checkorder+0xb3c) sp = 0xdc20cd28 fp = 0xdc20cd78 witness_checkorder() at witness_checkorder+0xb3c pc = 0xc0282b58 lr = 0xc022050c (__mtx_lock_spin_flags+0xc4) sp = 0xdc20cd80 fp = 0xdc20cda0 r4 = 0x00000000 r5 = 0x00000000 r6 = 0xc059198c r7 = 0xc059199c r8 = 0x00000000 r9 = 0x000000f0 r10 = 0xc04ba67a __mtx_lock_spin_flags() at __mtx_lock_spin_flags+0xc4 pc = 0xc022050c lr = 0xc02751a4 (sleepq_lock+0x34) sp = 0xdc20cda8 fp = 0xdc20cda8 r4 = 0xc2582960 r5 = 0x00000000 r6 = 0xc0580394 r7 = 0x00000000 r8 = 0xc2584c80 r9 = 0x00000000 r10 = 0xc0580390 sleepq_lock() at sleepq_lock+0x34 pc = 0xc02751a4 lr = 0xc023c4c0 (msleep_spin_sbt+0x80) sp = 0xdc20cdb0 fp = 0xdc20cdf0 msleep_spin_sbt() at msleep_spin_sbt+0x80 pc = 0xc023c4c0 lr = 0xc0147458 (random_kthread+0x270) sp = 0xdc20cdf8 fp = 0xdc20ce38 r4 = 0xc06f3c1c r5 = 0x00000000 r6 = 0xc049f1d1 r7 = 0x00000000 r8 = 0x00000000 r9 = 0x00000000 r10 = 0xc0580390 random_kthread() at random_kthread+0x270 pc = 0xc0147458 lr = 0xc02033f0 (fork_exit+0x88) sp = 0xdc20ce40 fp = 0xdc20ce58 r4 = 0xc2584c80 r5 = 0xc2582960 r6 = 0xc01471e8 r7 = 0x00000000 r8 = 0xdc20ce60 r9 = 0x00000000 r10 = 0x00000000 fork_exit() at fork_exit+0x88 pc = 0xc02033f0 lr = 0xc0475cec (fork_trampoline+0x14) sp = 0xdc20ce60 fp = 0x00000000 r4 = 0xc01471e8 r5 = 0x00000000 r6 = 0xc0c0c0c0 r7 = 0xc0c0c0c0 r8 = 0x00000000 fork_trampoline() at fork_trampoline+0x14 pc = 0xc0475cec lr = 0xc0475cec (fork_trampoline+0x14) sp = 0xdc20ce60 fp = 0x00000000 Unable to unwind further lock order reversal: 1st 0xc06f3c0c entropy harvest mutex (entropy harvest mutex) @ /usr/home/martin/Rasperry/head/sys/dev/random/randomdev_soft.c:242 2nd 0xc059198c sleepq chain (sleepq chain) @ /usr/home/martin/Rasperry/head/sys/kern/subr_sleepqueue.c:240 KDB: stack backtrace: db_trace_self() at db_trace_self pc = 0xc04652cc lr = 0xc012e474 (db_trace_self_wrapper+0x30) sp = 0xdc20cbf8 fp = 0xdc20cd10 r10 = 0xc06f3c0c db_trace_self_wrapper() at db_trace_self_wrapper+0x30 pc = 0xc012e474 lr = 0xc0268974 (kdb_backtrace+0x38) sp = 0xdc20cd18 fp = 0xdc20cd20 r4 = 0xc05908a4 r5 = 0xc04ba67d r6 = 0xc04bd04d r7 = 0xc049f1d4 kdb_backtrace() at kdb_backtrace+0x38 pc = 0xc0268974 lr = 0xc0282df8 (witness_checkorder+0xddc) sp = 0xdc20cd28 fp = 0xdc20cd78 r4 = 0xc04ba662 witness_checkorder() at witness_checkorder+0xddc pc = 0xc0282df8 lr = 0xc022050c (__mtx_lock_spin_flags+0xc4) sp = 0xdc20cd80 fp = 0xdc20cda0 r4 = 0x00000000 r5 = 0x00000000 r6 = 0xc059198c r7 = 0xc059199c r8 = 0x00000000 r9 = 0x000000f0 r10 = 0xc04ba67a __mtx_lock_spin_flags() at __mtx_lock_spin_flags+0xc4 pc = 0xc022050c lr = 0xc02751a4 (sleepq_lock+0x34) sp = 0xdc20cda8 fp = 0xdc20cda8 r4 = 0xc2582960 r5 = 0x00000000 r6 = 0xc0580394 r7 = 0x00000000 r8 = 0xc2584c80 r9 = 0x00000000 r10 = 0xc0580390 sleepq_lock() at sleepq_lock+0x34 pc = 0xc02751a4 lr = 0xc023c4c0 (msleep_spin_sbt+0x80) sp = 0xdc20cdb0 fp = 0xdc20cdf0 msleep_spin_sbt() at msleep_spin_sbt+0x80 pc = 0xc023c4c0 lr = 0xc0147458 (random_kthread+0x270) sp = 0xdc20cdf8 fp = 0xdc20ce38 r4 = 0xc06f3c1c r5 = 0x00000000 r6 = 0xc049f1d1 r7 = 0x00000000 r8 = 0x00000000 r9 = 0x00000000 r10 = 0xc0580390 random_kthread() at random_kthread+0x270 pc = 0xc0147458 lr = 0xc02033f0 (fork_exit+0x88) sp = 0xdc20ce40 fp = 0xdc20ce58 r4 = 0xc2584c80 r5 = 0xc2582960 r6 = 0xc01471e8 r7 = 0x00000000 r8 = 0xdc20ce60 r9 = 0x00000000 r10 = 0x00000000 fork_exit() at fork_exit+0x88 pc = 0xc02033f0 lr = 0xc0475cec (fork_trampoline+0x14) sp = 0xdc20ce60 fp = 0x00000000 r4 = 0xc01471e8 r5 = 0x00000000 r6 = 0xc0c0c0c0 r7 = 0xc0c0c0c0 r8 = 0x00000000 fork_trampoline() at fork_trampoline+0x14 pc = 0xc0475cec lr = 0xc0475cec (fork_trampoline+0x14) sp = 0xdc20ce60 fp = 0x00000000 Unable to unwind further usbus0: 480Mbps High Speed USB v2.0 ugen0.1: at usbus0 uhub0: on usbus0 uhub0: 1 port with 1 removable, self powered mmcsd0: 8GB at mmc0 50.0MHz/4bit/65535-block WARNING: WITNESS option enabled, expect reduced performance. WARNING: DIAGNOSTIC option enabled, expect reduced performance. mmcsd0: Error indicated: 1 Timeout mmcsd0: Error indicated: 1 Timeout Root mount waiting for: usbus0 ugen0.2: at usbus0 uhub1: on usbus0 uhub1: MTT enabled Root mount waiting for: usbus0 uhub1: 3 ports with 2 removable, self powered Root mount waiting for: usbus0 ugen0.3: at usbus0 smsc0: on usbus0 Trying to mount root from ufs:/dev/mmcsd0s2a [rw,noatime]... mountroot: waiting for device /dev/mmcsd0s2a ... smsc0: chip 0xec00, rev. 0002 miibus0: on smsc0 ukphy0: PHY 1 on miibus0 ukphy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto ue0: on smsc0 ue0: Ethernet address: b8:27:eb:1d:b7:5a Mounting from ufs:/dev/mmcsd0s2a failed with error 19. Loader variables: vfs.root.mountfrom=ufs:/dev/mmcsd0s2a vfs.root.mountfrom.options=rw,noatime Manual root filesystem specification: : [options] Mount using filesystem and with the specified (optional) option list. eg. ufs:/dev/da0s1a zfs:tank cd9660:/dev/acd0 ro (which is equivalent to: mount -t cd9660 -o ro /dev/acd0 /) ? List valid disk boot devices . Yield 1 second (for background tasks) Abort manual input mountroot> >Release-Note: >Audit-Trail: >Unformatted: From owner-freebsd-arm@FreeBSD.ORG Wed Aug 28 05:50:01 2013 Return-Path: Delivered-To: freebsd-arm@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 083E6651 for ; Wed, 28 Aug 2013 05:50:01 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id DBB492BEF for ; Wed, 28 Aug 2013 05:50:00 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r7S5o0SX000100 for ; Wed, 28 Aug 2013 05:50:00 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r7S5o0ax099998; Wed, 28 Aug 2013 05:50:00 GMT (envelope-from gnats) Resent-Date: Wed, 28 Aug 2013 05:50:00 GMT Resent-Message-Id: <201308280550.r7S5o0ax099998@freefall.freebsd.org> Resent-From: FreeBSD-gnats-submit@FreeBSD.org (GNATS Filer) Resent-To: freebsd-arm@FreeBSD.org Resent-Reply-To: FreeBSD-gnats-submit@FreeBSD.org, Martin Laabs 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 80EFD5BA for ; Wed, 28 Aug 2013 05:44:39 +0000 (UTC) (envelope-from nobody@FreeBSD.org) Received: from oldred.freebsd.org (oldred.freebsd.org [8.8.178.121]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 6E3352BCB for ; Wed, 28 Aug 2013 05:44:39 +0000 (UTC) Received: from oldred.freebsd.org ([127.0.1.6]) by oldred.freebsd.org (8.14.5/8.14.7) with ESMTP id r7S5idmh094481 for ; Wed, 28 Aug 2013 05:44:39 GMT (envelope-from nobody@oldred.freebsd.org) Received: (from nobody@localhost) by oldred.freebsd.org (8.14.5/8.14.5/Submit) id r7S5id9t094480; Wed, 28 Aug 2013 05:44:39 GMT (envelope-from nobody) Message-Id: <201308280544.r7S5id9t094480@oldred.freebsd.org> Date: Wed, 28 Aug 2013 05:44:39 GMT From: Martin Laabs To: freebsd-gnats-submit@FreeBSD.org X-Send-Pr-Version: www-3.1 Subject: arm/181602: Raspberry PI kernel panic after DHCP 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, 28 Aug 2013 05:50:01 -0000 >Number: 181602 >Category: arm >Synopsis: Raspberry PI kernel panic after DHCP >Confidential: no >Severity: non-critical >Priority: low >Responsible: freebsd-arm >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Wed Aug 28 05:50:00 UTC 2013 >Closed-Date: >Last-Modified: >Originator: Martin Laabs >Release: FreeBSD 10.0-CURRENT #0 r254955M >Organization: - >Environment: not available >Description: With the current r254955M build the kernel panics after receiving the DHCP answer. Currently I do not know whether this is directly related to network or is the following task in the init process. The full boot log is attached. It might be also in context with the lock order reversal: DHCPOFFER from 192.168.1.250 DHCPREQUEST on ue0 to 255.255.255.255 port 67 DHCPACK from 192.168.1.250 bound to 192.168.1.54 -- renewal in 300 seconds. lock order reversal: (sleepable after non-sleepable) 1st 0xc2857d78 so_rcv (so_rcv) @ /usr/home/martin/Rasperry/head/sys/kern/uipc_socket.c:1594 2nd 0xc2899a30 vm map (user) (vm map (user)) @ /usr/home/martin/Rasperry/head/sys/vm/vm_map.c:3816 KDB: stack backtrace: db_trace_self() at db_trace_self pc = 0xc04652cc lr = 0xc012e474 (db_trace_self_wrapper+0x30) sp = 0xdd3ee818 fp = 0xdd3ee930 r10 = 0xc2857d78 db_trace_self_wrapper() at db_trace_self_wrapper+0x30 pc = 0xc012e474 lr = 0xc0268974 (kdb_backtrace+0x38) sp = 0xdd3ee938 fp = 0xdd3ee940 r4 = 0xc05908a4 r5 = 0xc04dce80 r6 = 0xc04bd04d r7 = 0xc04c14dc kdb_backtrace() at kdb_backtrace+0x38 pc = 0xc0268974 lr = 0xc0282df8 (witness_checkorder+0xddc) sp = 0xdd3ee948 fp = 0xdd3ee998 r4 = 0xc04bd221 witness_checkorder() at witness_checkorder+0xddc pc = 0xc0282df8 lr = 0xc023aaf0 (_sx_slock+0x84) sp = 0xdd3ee9a0 fp = 0xdd3ee9c8 r4 = 0x00000ee8 r5 = 0xc04dce7d r6 = 0xc2899a30 r7 = 0xc2899a40 r8 = 0x00000000 r9 = 0x00000000 r10 = 0xdd3eeb2c _sx_slock() at _sx_slock+0x84 pc = 0xc023aaf0 lr = 0xc044579c (vm_map_lookup+0x74) sp = 0xdd3ee9d0 fp = 0xdd3eea08 r4 = 0xc28999e0 r5 = 0xc04dce7d r6 = 0x3601a000 r7 = 0x3601a000 r8 = 0x00000002 vm_map_lookup() at vm_map_lookup+0x74 pc = 0xc044579c lr = 0xc0439a18 (vm_fault_hold+0xe4) sp = 0xdd3eea10 fp = 0xdd3eeb80 r4 = 0xc28999e0 r5 = 0x00000002 r6 = 0xc2819960 r7 = 0x3601a000 r8 = 0xdd3eeb10 r9 = 0x00000000 r10 = 0xc06f7af0 vm_fault_hold() at vm_fault_hold+0xe4 pc = 0xc0439a18 lr = 0xc04398ec (vm_fault+0x88) sp = 0xdd3eeb88 fp = 0xdd3eeba8 r4 = 0xc28999e0 r5 = 0x00000002 r6 = 0xc2819960 r7 = 0x3601a000 r8 = 0x00000000 r9 = 0x00000002 r10 = 0xc06f7af0 vm_fault() at vm_fault+0x88 pc = 0xc04398ec lr = 0xc04760fc (data_abort_handler+0x2a8) sp = 0xdd3eebb0 fp = 0xdd3eec50 r4 = 0xc2872640 r5 = 0xc2819960 r6 = 0xc04e30cc r7 = 0xc28726e8 r8 = 0xdd3eec58 r9 = 0xdd3eeeb0 r10 = 0xc28999e0 data_abort_handler() at data_abort_handler+0x2a8 pc = 0xc04760fc lr = 0xc0466b04 (exception_exit) sp = 0xdd3eec58 fp = 0xdd3eed10 r4 = 0xc056b1cc r5 = 0xc2857da4 r6 = 0xc2857d00 r7 = 0x3601a8c0 r8 = 0x00000000 r9 = 0xc2857d88 r10 = 0xc272fd00 exception_exit() at exception_exit pc = 0xc0466b04 lr = 0xc2819960 (0xc2819960) sp = 0xdd3eecac fp = 0xdd3eed10 r0 = 0x3601a8c0 r1 = 0xc272fb00 r2 = 0xc04c14d9 r3 = 0x000005ef r4 = 0xc056b1cc r5 = 0xc2857da4 r6 = 0xc2857d00 r7 = 0x3601a8c0 r8 = 0x00000000 r9 = 0xc2857d88 r10 = 0xc272fd00 r12 = 0x00000000 soreceive_generic() at soreceive_generic+0x4a8 pc = 0xc02a9aec lr = 0xc02ab784 (soreceive+0x2c) sp = 0xdd3eed18 fp = 0xdd3eed20 r4 = 0xc2819960 r5 = 0x00000000 r6 = 0xdd3eed98 r7 = 0x00000000 r8 = 0x00000006 r9 = 0xc27c5c40 r10 = 0x00000800 soreceive() at soreceive+0x2c pc = 0xc02ab784 lr = 0xc028da28 (soo_read+0x2c) sp = 0xdd3eed28 fp = 0xdd3eed30 soo_read() at soo_read+0x2c pc = 0xc028da28 lr = 0xc0286aa4 (dofileread+0xa8) sp = 0xdd3eed38 fp = 0xdd3eed58 dofileread() at dofileread+0xa8 pc = 0xc0286aa4 lr = 0xc0286764 (kern_readv+0x60) sp = 0xdd3eed60 fp = 0xdd3eed88 r4 = 0xffffffff r5 = 0x00000000 r6 = 0x00000000 r7 = 0x00000006 r8 = 0xdd3eed98 r9 = 0xc2819960 r10 = 0x2081f0f0 kern_readv() at kern_readv+0x60 pc = 0xc0286764 lr = 0xc02866f4 (sys_read+0x4c) sp = 0xdd3eed90 fp = 0xdd3eedb8 r4 = 0xc2819960 r5 = 0x00000000 r6 = 0xbfffe5a0 r7 = 0x00000000 r8 = 0xdd3eee10 r9 = 0xc2872640 sys_read() at sys_read+0x4c pc = 0xc02866f4 lr = 0xc0476bc4 (swi_handler+0x284) sp = 0xdd3eedc0 fp = 0xdd3eee58 swi_handler() at swi_handler+0x284 pc = 0xc0476bc4 lr = 0xc0466928 (swi_entry+0x2c) sp = 0xdd3eee60 fp = 0xbfffedc0 r4 = 0x000378f8 r5 = 0x0002d258 r6 = 0xbfffe5a0 r7 = 0x00000003 r8 = 0x00000000 r9 = 0x521d3af3 swi_entry() at swi_entry+0x2c pc = 0xc0466928 lr = 0xc0466928 (swi_entry+0x2c) sp = 0xdd3eee60 fp = 0xbfffedc0 Unable to unwind further vm_fault(0xc28999e0, 3601a000, 2, 0) -> 5 Fatal kernel mode data abort: 'Translation Fault (S)' trapframe: 0xdd3eec58 FSR=00000805, FAR=3601a8c4, spsr=20000013 r0 =3601a8c0, r1 =c272fb00, r2 =c04c14d9, r3 =000005ef r4 =c056b1cc, r5 =c2857da4, r6 =c2857d00, r7 =3601a8c0 r8 =00000000, r9 =c2857d88, r10=c272fd00, r11=dd3eed10 r12=00000000, ssp=dd3eeca8, slr=c2819960, pc =c02a9aec [ thread pid 542 tid 100059 ] Stopped at soreceive_generic+0x4a8: str r1, [r0, #0x004] db> >How-To-Repeat: Build current for Rasperry Pi and run >Fix: Patch attached with submission follows: U-Boot 2013.01-rc1-g6709570-dirty (Aug 17 2013 - 23:35:05) DRAM: 480 MiB WARNING: Caches not enabled MMC: bcm2835_sdhci: 0 Using default environment In: serial Out: lcd Err: lcd mbox: Timeout waiting for response bcm2835: Could not set USB power state Net: Net Initialization Skipped No ethernet found. Hit any key to stop autoboot: 3  2  1  0 reading uEnv.txt 89 bytes read in 9541 ms (0 Bytes/s) Importing environment from mmc ... reading ubldr 239540 bytes read in 54396 ms (3.9 KiB/s) ## Starting application at 0x02000054 ... Consoles: U-Boot console Compatible API signature found @1db682a8 Number of U-Boot devices: 1 FreeBSD/armv6 U-Boot loader, Revision 1.2 (martin@pcbsd-7130, Wed Aug 28 01:32:51 CEST 2013) DRAM: 480MB Device: disk |/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|Loading /boot/defaults/loader.conf /-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\/boot/kernel/kernel data=0x47b5e4+0x17e19c |/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|syms=[0x4+0x7fcb0/-\|/-\|/-\|/-\|+0x4+0x4d613/-\|/-\|/-] Hit [Enter] to boot immediately, or any other key for command prompt. Booting [/boot/kernel/kernel]... \|/-\|/Using DTB provided by U-Boot. Kernel entry at 0x100100... Kernel args: (null) 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-CURRENT #0 r254955M: Wed Aug 28 01:32:36 CEST 2013 martin@pcbsd-7130:/usr/home/martin/Rasperry/crochet-freebsd/work/obj/arm.armv6/usr/home/martin/Rasperry/head/sys/RPI-B arm FreeBSD clang version 3.3 (tags/RELEASE_33/final 183502) 20130610 WARNING: WITNESS option enabled, expect reduced performance. WARNING: DIAGNOSTIC option enabled, expect reduced performance. CPU: 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 = 536870912 (512 MB) avail memory = 482902016 (460 MB) random device not loaded; using insecure entropy 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 bcm_dma0: mem 0x20007000-0x20007fff,0x20e05000-0x20e05fff irq 24,25,26,27,28,29,30,31,32,33,34,35,36 on simplebus0 mbox0: mem 0x2000b880-0x2000b8bf irq 1 on simplebus0 sdhci_bcm0: mem 0x20300000-0x203000ff irq 70 on simplebus0 mmc0: on sdhci_bcm0 uart0: mem 0x20201000-0x20201fff irq 65 on simplebus0 uart0: console (115200,n,8,1) dwcotg0: mem 0x20980000-0x2099ffff irq 17 on simplebus0 usbus0 on dwcotg0 simplebus1: on fdtbus0 Timecounters tick every 10.000 msec lock order reversal: 1st 0xc06f3c0c entropy harvest mutex (entropy harvest mutex) @ /usr/home/martin/Rasperry/head/sys/dev/random/randomdev_soft.c:242 2nd 0xc25d7c20 uart_hwmtx (uart_hwmtx) @ /usr/home/martin/Rasperry/head/sys/dev/uart/uart_cpu.h:92 KDB: stack backtrace: db_trace_self() at db_trace_self pc = 0xc04652cc lr = 0xc012e474 (db_trace_self_wrapper+0x30) sp = 0xdc20c9c8 fp = 0xdc20cae0 r10 = 0xc06f3c0c db_trace_self_wrapper() at db_trace_self_wrapper+0x30 pc = 0xc012e474 lr = 0xc0268974 (kdb_backtrace+0x38) sp = 0xdc20cae8 fp = 0xdc20caf0 r4 = 0xc05908a4 r5 = 0xc049fb59 r6 = 0xc04bd04d r7 = 0xc049f1d4 kdb_backtrace() at kdb_backtrace+0x38 pc = 0xc0268974 lr = 0xc0282df8 (witness_checkorder+0xddc) sp = 0xdc20caf8 fp = 0xdc20cb48 r4 = 0xc049fa8a witness_checkorder() at witness_checkorder+0xddc pc = 0xc0282df8 lr = 0xc022050c (__mtx_lock_spin_flags+0xc4) sp = 0xdc20cb50 fp = 0xdc20cb70 r4 = 0x00000000 r5 = 0xc0580a84 r6 = 0xc25d7c20 r7 = 0xc25d7c30 r8 = 0x00000000 r9 = 0x0000005c r10 = 0xc049fb56 __mtx_lock_spin_flags() at __mtx_lock_spin_flags+0xc4 pc = 0xc022050c lr = 0xc014e9a4 (uart_cnputc+0x44) sp = 0xdc20cb78 fp = 0xdc20cb88 r4 = 0x0000006c r5 = 0xc0580a84 r6 = 0xc05908a0 r7 = 0xc0581700 r8 = 0xc055d590 r9 = 0xc05816e0 r10 = 0xdc20ccf0 uart_cnputc() at uart_cnputc+0x44 pc = 0xc014e9a4 lr = 0xc01eb6b0 (cnputc+0x80) sp = 0xdc20cb90 fp = 0xdc20cba8 r4 = 0x0000006c r5 = 0xc0551c30 r6 = 0xc05908a0 cnputc() at cnputc+0x80 pc = 0xc01eb6b0 lr = 0xc026e6ec (putchar+0x194) sp = 0xdc20cbb0 fp = 0xdc20cc18 r4 = 0x00000005 r5 = 0xdc20ccf0 r6 = 0x0000006c r7 = 0x00000000 r8 = 0xc06f52b4 r9 = 0xc026e558 putchar() at putchar+0x194 pc = 0xc026e6ec lr = 0xc026d53c (kvprintf+0xb0) sp = 0xdc20cc20 fp = 0xdc20ccd8 r4 = 0xc04bc4c4 r5 = 0x00000000 r6 = 0x00000000 r7 = 0x00000000 r8 = 0xc06f52b4 r9 = 0xc026e558 r10 = 0xdc20ccf0 kvprintf() at kvprintf+0xb0 pc = 0xc026d53c lr = 0xc026ec58 (printf+0x50) sp = 0xdc20cce0 fp = 0xdc20cd10 r4 = 0xc2446da8 r5 = 0xc2446a68 r6 = 0x00000000 r7 = 0xc06c394c r8 = 0xc06f52b4 r9 = 0x00000001 r10 = 0xc06c395b printf() at printf+0x50 pc = 0xc026ec58 lr = 0xc0282b58 (witness_checkorder+0xb3c) sp = 0xdc20cd28 fp = 0xdc20cd78 witness_checkorder() at witness_checkorder+0xb3c pc = 0xc0282b58 lr = 0xc022050c (__mtx_lock_spin_flags+0xc4) sp = 0xdc20cd80 fp = 0xdc20cda0 r4 = 0x00000000 r5 = 0x00000000 r6 = 0xc059198c r7 = 0xc059199c r8 = 0x00000000 r9 = 0x000000f0 r10 = 0xc04ba67a __mtx_lock_spin_flags() at __mtx_lock_spin_flags+0xc4 pc = 0xc022050c lr = 0xc02751a4 (sleepq_lock+0x34) sp = 0xdc20cda8 fp = 0xdc20cda8 r4 = 0xc2582960 r5 = 0x00000000 r6 = 0xc0580394 r7 = 0x00000000 r8 = 0xc2584c80 r9 = 0x00000000 r10 = 0xc0580390 sleepq_lock() at sleepq_lock+0x34 pc = 0xc02751a4 lr = 0xc023c4c0 (msleep_spin_sbt+0x80) sp = 0xdc20cdb0 fp = 0xdc20cdf0 msleep_spin_sbt() at msleep_spin_sbt+0x80 pc = 0xc023c4c0 lr = 0xc0147458 (random_kthread+0x270) sp = 0xdc20cdf8 fp = 0xdc20ce38 r4 = 0xc06f3c1c r5 = 0x00000000 r6 = 0xc049f1d1 r7 = 0x00000000 r8 = 0x00000000 r9 = 0x00000000 r10 = 0xc0580390 random_kthread() at random_kthread+0x270 pc = 0xc0147458 lr = 0xc02033f0 (fork_exit+0x88) sp = 0xdc20ce40 fp = 0xdc20ce58 r4 = 0xc2584c80 r5 = 0xc2582960 r6 = 0xc01471e8 r7 = 0x00000000 r8 = 0xdc20ce60 r9 = 0x00000000 r10 = 0x00000000 fork_exit() at fork_exit+0x88 pc = 0xc02033f0 lr = 0xc0475cec (fork_trampoline+0x14) sp = 0xdc20ce60 fp = 0x00000000 r4 = 0xc01471e8 r5 = 0x00000000 r6 = 0xc0c0c0c0 r7 = 0xc0c0c0c0 r8 = 0x00000000 fork_trampoline() at fork_trampoline+0x14 pc = 0xc0475cec lr = 0xc0475cec (fork_trampoline+0x14) sp = 0xdc20ce60 fp = 0x00000000 Unable to unwind further lock order reversal: 1st 0xc06f3c0c entropy harvest mutex (entropy harvest mutex) @ /usr/home/martin/Rasperry/head/sys/dev/random/randomdev_soft.c:242 2nd 0xc059198c sleepq chain (sleepq chain) @ /usr/home/martin/Rasperry/head/sys/kern/subr_sleepqueue.c:240 KDB: stack backtrace: db_trace_self() at db_trace_self pc = 0xc04652cc lr = 0xc012e474 (db_trace_self_wrapper+0x30) sp = 0xdc20cbf8 fp = 0xdc20cd10 r10 = 0xc06f3c0c db_trace_self_wrapper() at db_trace_self_wrapper+0x30 pc = 0xc012e474 lr = 0xc0268974 (kdb_backtrace+0x38) sp = 0xdc20cd18 fp = 0xdc20cd20 r4 = 0xc05908a4 r5 = 0xc04ba67d r6 = 0xc04bd04d r7 = 0xc049f1d4 kdb_backtrace() at kdb_backtrace+0x38 pc = 0xc0268974 lr = 0xc0282df8 (witness_checkorder+0xddc) sp = 0xdc20cd28 fp = 0xdc20cd78 r4 = 0xc04ba662 witness_checkorder() at witness_checkorder+0xddc pc = 0xc0282df8 lr = 0xc022050c (__mtx_lock_spin_flags+0xc4) sp = 0xdc20cd80 fp = 0xdc20cda0 r4 = 0x00000000 r5 = 0x00000000 r6 = 0xc059198c r7 = 0xc059199c r8 = 0x00000000 r9 = 0x000000f0 r10 = 0xc04ba67a __mtx_lock_spin_flags() at __mtx_lock_spin_flags+0xc4 pc = 0xc022050c lr = 0xc02751a4 (sleepq_lock+0x34) sp = 0xdc20cda8 fp = 0xdc20cda8 r4 = 0xc2582960 r5 = 0x00000000 r6 = 0xc0580394 r7 = 0x00000000 r8 = 0xc2584c80 r9 = 0x00000000 r10 = 0xc0580390 sleepq_lock() at sleepq_lock+0x34 pc = 0xc02751a4 lr = 0xc023c4c0 (msleep_spin_sbt+0x80) sp = 0xdc20cdb0 fp = 0xdc20cdf0 msleep_spin_sbt() at msleep_spin_sbt+0x80 pc = 0xc023c4c0 lr = 0xc0147458 (random_kthread+0x270) sp = 0xdc20cdf8 fp = 0xdc20ce38 r4 = 0xc06f3c1c r5 = 0x00000000 r6 = 0xc049f1d1 r7 = 0x00000000 r8 = 0x00000000 r9 = 0x00000000 r10 = 0xc0580390 random_kthread() at random_kthread+0x270 pc = 0xc0147458 lr = 0xc02033f0 (fork_exit+0x88) sp = 0xdc20ce40 fp = 0xdc20ce58 r4 = 0xc2584c80 r5 = 0xc2582960 r6 = 0xc01471e8 r7 = 0x00000000 r8 = 0xdc20ce60 r9 = 0x00000000 r10 = 0x00000000 fork_exit() at fork_exit+0x88 pc = 0xc02033f0 lr = 0xc0475cec (fork_trampoline+0x14) sp = 0xdc20ce60 fp = 0x00000000 r4 = 0xc01471e8 r5 = 0x00000000 r6 = 0xc0c0c0c0 r7 = 0xc0c0c0c0 r8 = 0x00000000 fork_trampoline() at fork_trampoline+0x14 pc = 0xc0475cec lr = 0xc0475cec (fork_trampoline+0x14) sp = 0xdc20ce60 fp = 0x00000000 Unable to unwind further usbus0: 480Mbps High Speed USB v2.0 ugen0.1: at usbus0 uhub0: on usbus0 uhub0: 1 port with 1 removable, self powered mmcsd0: 8GB at mmc0 50.0MHz/4bit/65535-block WARNING: WITNESS option enabled, expect reduced performance. WARNING: DIAGNOSTIC option enabled, expect reduced performance. mmcsd0: Error indicated: 1 Timeout mmcsd0: Error indicated: 1 Timeout Root mount waiting for: usbus0 ugen0.2: at usbus0 uhub1: on usbus0 uhub1: MTT enabled Root mount waiting for: usbus0 uhub1: 3 ports with 2 removable, self powered Root mount waiting for: usbus0 ugen0.3: at usbus0 smsc0: on usbus0 Trying to mount root from ufs:/dev/mmcsd0s2a [rw,noatime]... mountroot: waiting for device /dev/mmcsd0s2a ... smsc0: chip 0xec00, rev. 0002 miibus0: on smsc0 ukphy0: PHY 1 on miibus0 ukphy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto ue0: on smsc0 ue0: Ethernet address: b8:27:eb:1d:b7:5a Mounting from ufs:/dev/mmcsd0s2a failed with error 19. Loader variables: vfs.root.mountfrom=ufs:/dev/mmcsd0s2a vfs.root.mountfrom.options=rw,noatime Manual root filesystem specification: : [options] Mount using filesystem and with the specified (optional) option list. eg. ufs:/dev/da0s1a zfs:tank cd9660:/dev/acd0 ro (which is equivalent to: mount -t cd9660 -o ro /dev/acd0 /) ? List valid disk boot devices . Yield 1 second (for background tasks) Abort manual input mountroot> kickstart. Starting file system checks: ** SU+J Recovering /dev/mmcsd0s2a ** Reading 4194304 byte journal from inode 4. ** Building recovery table. ** Resolving unreferenced inode list. ** Processing journal entries. ** 31 journal records in 4608 bytes for 21.53% utilization ** Freed 0 inodes (0 dirs) 0 blocks, and 0 frags. ***** FILE SYSTEM MARKED CLEAN ***** Mounting local file systems:. Writing entropy file:. Setting hostname: raspberry-pi. smsc0: chip 0xec00, rev. 0002 ue0: link state changed to DOWN ue0: link state changed to UP Starting Network: lo0 ue0. lo0: flags=8049 metric 0 mtu 16384 options=600003 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1 inet 127.0.0.1 netmask 0xff000000 nd6 options=21 ue0: flags=8843 metric 0 mtu 1500 options=80001 ether b8:27:eb:1d:b7:5a media: Ethernet autoselect (100baseTX ) status: active nd6 options=29 Starting devd. Starting dhclient. DHCPDISCOVER on ue0 to 255.255.255.255 port 67 interval 4 DHCPOFFER from 192.168.1.250 DHCPREQUEST on ue0 to 255.255.255.255 port 67 DHCPACK from 192.168.1.250 bound to 192.168.1.54 -- renewal in 300 seconds. lock order reversal: (sleepable after non-sleepable) 1st 0xc2857d78 so_rcv (so_rcv) @ /usr/home/martin/Rasperry/head/sys/kern/uipc_socket.c:1594 2nd 0xc2898a30 vm map (user) (vm map (user)) @ /usr/home/martin/Rasperry/head/sys/vm/vm_map.c:3816 KDB: stack backtrace: db_trace_self() at db_trace_self pc = 0xc04652cc lr = 0xc012e474 (db_trace_self_wrapper+0x30) sp = 0xdd3ee818 fp = 0xdd3ee930 r10 = 0xc2857d78 db_trace_self_wrapper() at db_trace_self_wrapper+0x30 pc = 0xc012e474 lr = 0xc0268974 (kdb_backtrace+0x38) sp = 0xdd3ee938 fp = 0xdd3ee940 r4 = 0xc05908a4 r5 = 0xc04dce80 r6 = 0xc04bd04d r7 = 0xc04c14dc kdb_backtrace() at kdb_backtrace+0x38 pc = 0xc0268974 lr = 0xc0282df8 (witness_checkorder+0xddc) sp = 0xdd3ee948 fp = 0xdd3ee998 r4 = 0xc04bd221 witness_checkorder() at witness_checkorder+0xddc pc = 0xc0282df8 lr = 0xc023aaf0 (_sx_slock+0x84) sp = 0xdd3ee9a0 fp = 0xdd3ee9c8 r4 = 0x00000ee8 r5 = 0xc04dce7d r6 = 0xc2898a30 r7 = 0xc2898a40 r8 = 0x00000000 r9 = 0x00000000 r10 = 0xdd3eeb2c _sx_slock() at _sx_slock+0x84 pc = 0xc023aaf0 lr = 0xc044579c (vm_map_lookup+0x74) sp = 0xdd3ee9d0 fp = 0xdd3eea08 r4 = 0xc28989e0 r5 = 0xc04dce7d r6 = 0x3601a000 r7 = 0x3601a000 r8 = 0x00000002 vm_map_lookup() at vm_map_lookup+0x74 pc = 0xc044579c lr = 0xc0439a18 (vm_fault_hold+0xe4) sp = 0xdd3eea10 fp = 0xdd3eeb80 r4 = 0xc28989e0 r5 = 0x00000002 r6 = 0xc2819960 r7 = 0x3601a000 r8 = 0xdd3eeb10 r9 = 0x00000000 r10 = 0xc06f7af0 vm_fault_hold() at vm_fault_hold+0xe4 pc = 0xc0439a18 lr = 0xc04398ec (vm_fault+0x88) sp = 0xdd3eeb88 fp = 0xdd3eeba8 r4 = 0xc28989e0 r5 = 0x00000002 r6 = 0xc2819960 r7 = 0x3601a000 r8 = 0x00000000 r9 = 0x00000002 r10 = 0xc06f7af0 vm_fault() at vm_fault+0x88 pc = 0xc04398ec lr = 0xc04760fc (data_abort_handler+0x2a8) sp = 0xdd3eebb0 fp = 0xdd3eec50 r4 = 0xc2872640 r5 = 0xc2819960 r6 = 0xc04e30cc r7 = 0xc28726e8 r8 = 0xdd3eec58 r9 = 0xdd3eeeb0 r10 = 0xc28989e0 data_abort_handler() at data_abort_handler+0x2a8 pc = 0xc04760fc lr = 0xc0466b04 (exception_exit) sp = 0xdd3eec58 fp = 0xdd3eed10 r4 = 0xc056b1cc r5 = 0xc2857da4 r6 = 0xc2857d00 r7 = 0x3601a8c0 r8 = 0x00000000 r9 = 0xc2857d88 r10 = 0xc272fd00 exception_exit() at exception_exit pc = 0xc0466b04 lr = 0xc2819960 (0xc2819960) sp = 0xdd3eecac fp = 0xdd3eed10 r0 = 0x3601a8c0 r1 = 0xc272fb00 r2 = 0xc04c14d9 r3 = 0x000005ef r4 = 0xc056b1cc r5 = 0xc2857da4 r6 = 0xc2857d00 r7 = 0x3601a8c0 r8 = 0x00000000 r9 = 0xc2857d88 r10 = 0xc272fd00 r12 = 0x00000000 soreceive_generic() at soreceive_generic+0x4a8 pc = 0xc02a9aec lr = 0xc02ab784 (soreceive+0x2c) sp = 0xdd3eed18 fp = 0xdd3eed20 r4 = 0xc2819960 r5 = 0x00000000 r6 = 0xdd3eed98 r7 = 0x00000000 r8 = 0x00000006 r9 = 0xc27c5c40 r10 = 0x00000800 soreceive() at soreceive+0x2c pc = 0xc02ab784 lr = 0xc028da28 (soo_read+0x2c) sp = 0xdd3eed28 fp = 0xdd3eed30 soo_read() at soo_read+0x2c pc = 0xc028da28 lr = 0xc0286aa4 (dofileread+0xa8) sp = 0xdd3eed38 fp = 0xdd3eed58 dofileread() at dofileread+0xa8 pc = 0xc0286aa4 lr = 0xc0286764 (kern_readv+0x60) sp = 0xdd3eed60 fp = 0xdd3eed88 r4 = 0xffffffff r5 = 0x00000000 r6 = 0x00000000 r7 = 0x00000006 r8 = 0xdd3eed98 r9 = 0xc2819960 r10 = 0x2081f0f0 kern_readv() at kern_readv+0x60 pc = 0xc0286764 lr = 0xc02866f4 (sys_read+0x4c) sp = 0xdd3eed90 fp = 0xdd3eedb8 r4 = 0xc2819960 r5 = 0x00000000 r6 = 0xbfffe5a0 r7 = 0x00000000 r8 = 0xdd3eee10 r9 = 0xc2872640 sys_read() at sys_read+0x4c pc = 0xc02866f4 lr = 0xc0476bc4 (swi_handler+0x284) sp = 0xdd3eedc0 fp = 0xdd3eee58 swi_handler() at swi_handler+0x284 pc = 0xc0476bc4 lr = 0xc0466928 (swi_entry+0x2c) sp = 0xdd3eee60 fp = 0xbfffedc0 r4 = 0x000378f8 r5 = 0x0002d258 r6 = 0xbfffe5a0 r7 = 0x00000003 r8 = 0x00000000 r9 = 0x521d3a99 swi_entry() at swi_entry+0x2c pc = 0xc0466928 lr = 0xc0466928 (swi_entry+0x2c) sp = 0xdd3eee60 fp = 0xbfffedc0 Unable to unwind further vm_fault(0xc28989e0, 3601a000, 2, 0) -> 5 Fatal kernel mode data abort: 'Translation Fault (S)' trapframe: 0xdd3eec58 FSR=00000805, FAR=3601a8c4, spsr=20000013 r0 =3601a8c0, r1 =c272fb00, r2 =c04c14d9, r3 =000005ef r4 =c056b1cc, r5 =c2857da4, r6 =c2857d00, r7 =3601a8c0 r8 =00000000, r9 =c2857d88, r10=c272fd00, r11=dd3eed10 r12=00000000, ssp=dd3eeca8, slr=c2819960, pc =c02a9aec [ thread pid 542 tid 100059 ] Stopped at soreceive_generic+0x4a8: str r1, [r0, #0x004] db> U-Boot 2013.01-rc1-g6709570-dirty (Aug 17 2013 - 23:35:05) DRAM: 480 MiB WARNING: Caches not enabled MMC: bcm2835_sdhci: 0 Using default environment In: serial Out: lcd Err: lcd mbox: Timeout waiting for response bcm2835: Could not set USB power state Net: Net Initialization Skipped No ethernet found. Hit any key to stop autoboot: 3  2  1  0 reading uEnv.txt 89 bytes read in 9553 ms (0 Bytes/s) Importing environment from mmc ... reading ubldr 239540 bytes read in 54380 ms (3.9 KiB/s) ## Starting application at 0x02000054 ... Consoles: U-Boot console Compatible API signature found @1db682a8 Number of U-Boot devices: 1 FreeBSD/armv6 U-Boot loader, Revision 1.2 (martin@pcbsd-7130, Wed Aug 28 01:32:51 CEST 2013) DRAM: 480MB Device: disk |/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|Loading /boot/defaults/loader.conf /-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\/boot/kernel/kernel data=0x47b5e4+0x17e19c |/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|syms=[0x4+0x7fcb0/-\|/-\|/-\|/-\|+0x4+0x4d613/-\|/-\|/-] Hit [Enter] to boot immediately, or any other key for command prompt. Booting [/boot/kernel/kernel]... \|/-\|/Using DTB provided by U-Boot. Kernel entry at 0x100100... Kernel args: (null) 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-CURRENT #0 r254955M: Wed Aug 28 01:32:36 CEST 2013 martin@pcbsd-7130:/usr/home/martin/Rasperry/crochet-freebsd/work/obj/arm.armv6/usr/home/martin/Rasperry/head/sys/RPI-B arm FreeBSD clang version 3.3 (tags/RELEASE_33/final 183502) 20130610 WARNING: WITNESS option enabled, expect reduced performance. WARNING: DIAGNOSTIC option enabled, expect reduced performance. CPU: 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 = 536870912 (512 MB) avail memory = 482902016 (460 MB) random device not loaded; using insecure entropy 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 bcm_dma0: mem 0x20007000-0x20007fff,0x20e05000-0x20e05fff irq 24,25,26,27,28,29,30,31,32,33,34,35,36 on simplebus0 mbox0: mem 0x2000b880-0x2000b8bf irq 1 on simplebus0 sdhci_bcm0: mem 0x20300000-0x203000ff irq 70 on simplebus0 mmc0: on sdhci_bcm0 uart0: mem 0x20201000-0x20201fff irq 65 on simplebus0 uart0: console (115200,n,8,1) dwcotg0: mem 0x20980000-0x2099ffff irq 17 on simplebus0 usbus0 on dwcotg0 simplebus1: on fdtbus0 Timecounters tick every 10.000 msec lock order reversal: 1st 0xc06f3c0c entropy harvest mutex (entropy harvest mutex) @ /usr/home/martin/Rasperry/head/sys/dev/random/randomdev_soft.c:242 2nd 0xc25d7c20 uart_hwmtx (uart_hwmtx) @ /usr/home/martin/Rasperry/head/sys/dev/uart/uart_cpu.h:92 KDB: stack backtrace: db_trace_self() at db_trace_self pc = 0xc04652cc lr = 0xc012e474 (db_trace_self_wrapper+0x30) sp = 0xdc20c9c8 fp = 0xdc20cae0 r10 = 0xc06f3c0c db_trace_self_wrapper() at db_trace_self_wrapper+0x30 pc = 0xc012e474 lr = 0xc0268974 (kdb_backtrace+0x38) sp = 0xdc20cae8 fp = 0xdc20caf0 r4 = 0xc05908a4 r5 = 0xc049fb59 r6 = 0xc04bd04d r7 = 0xc049f1d4 kdb_backtrace() at kdb_backtrace+0x38 pc = 0xc0268974 lr = 0xc0282df8 (witness_checkorder+0xddc) sp = 0xdc20caf8 fp = 0xdc20cb48 r4 = 0xc049fa8a witness_checkorder() at witness_checkorder+0xddc pc = 0xc0282df8 lr = 0xc022050c (__mtx_lock_spin_flags+0xc4) sp = 0xdc20cb50 fp = 0xdc20cb70 r4 = 0x00000000 r5 = 0xc0580a84 r6 = 0xc25d7c20 r7 = 0xc25d7c30 r8 = 0x00000000 r9 = 0x0000005c r10 = 0xc049fb56 __mtx_lock_spin_flags() at __mtx_lock_spin_flags+0xc4 pc = 0xc022050c lr = 0xc014e9a4 (uart_cnputc+0x44) sp = 0xdc20cb78 fp = 0xdc20cb88 r4 = 0x0000006c r5 = 0xc0580a84 r6 = 0xc05908a0 r7 = 0xc0581700 r8 = 0xc055d590 r9 = 0xc05816e0 r10 = 0xdc20ccf0 uart_cnputc() at uart_cnputc+0x44 pc = 0xc014e9a4 lr = 0xc01eb6b0 (cnputc+0x80) sp = 0xdc20cb90 fp = 0xdc20cba8 r4 = 0x0000006c r5 = 0xc0551c30 r6 = 0xc05908a0 cnputc() at cnputc+0x80 pc = 0xc01eb6b0 lr = 0xc026e6ec (putchar+0x194) sp = 0xdc20cbb0 fp = 0xdc20cc18 r4 = 0x00000005 r5 = 0xdc20ccf0 r6 = 0x0000006c r7 = 0x00000000 r8 = 0xc06f52b4 r9 = 0xc026e558 putchar() at putchar+0x194 pc = 0xc026e6ec lr = 0xc026d53c (kvprintf+0xb0) sp = 0xdc20cc20 fp = 0xdc20ccd8 r4 = 0xc04bc4c4 r5 = 0x00000000 r6 = 0x00000000 r7 = 0x00000000 r8 = 0xc06f52b4 r9 = 0xc026e558 r10 = 0xdc20ccf0 kvprintf() at kvprintf+0xb0 pc = 0xc026d53c lr = 0xc026ec58 (printf+0x50) sp = 0xdc20cce0 fp = 0xdc20cd10 r4 = 0xc2446da8 r5 = 0xc2446a68 r6 = 0x00000000 r7 = 0xc06c394c r8 = 0xc06f52b4 r9 = 0x00000001 r10 = 0xc06c395b printf() at printf+0x50 pc = 0xc026ec58 lr = 0xc0282b58 (witness_checkorder+0xb3c) sp = 0xdc20cd28 fp = 0xdc20cd78 witness_checkorder() at witness_checkorder+0xb3c pc = 0xc0282b58 lr = 0xc022050c (__mtx_lock_spin_flags+0xc4) sp = 0xdc20cd80 fp = 0xdc20cda0 r4 = 0x00000000 r5 = 0x00000000 r6 = 0xc059198c r7 = 0xc059199c r8 = 0x00000000 r9 = 0x000000f0 r10 = 0xc04ba67a __mtx_lock_spin_flags() at __mtx_lock_spin_flags+0xc4 pc = 0xc022050c lr = 0xc02751a4 (sleepq_lock+0x34) sp = 0xdc20cda8 fp = 0xdc20cda8 r4 = 0xc2582960 r5 = 0x00000000 r6 = 0xc0580394 r7 = 0x00000000 r8 = 0xc2584c80 r9 = 0x00000000 r10 = 0xc0580390 sleepq_lock() at sleepq_lock+0x34 pc = 0xc02751a4 lr = 0xc023c4c0 (msleep_spin_sbt+0x80) sp = 0xdc20cdb0 fp = 0xdc20cdf0 msleep_spin_sbt() at msleep_spin_sbt+0x80 pc = 0xc023c4c0 lr = 0xc0147458 (random_kthread+0x270) sp = 0xdc20cdf8 fp = 0xdc20ce38 r4 = 0xc06f3c1c r5 = 0x00000000 r6 = 0xc049f1d1 r7 = 0x00000000 r8 = 0x00000000 r9 = 0x00000000 r10 = 0xc0580390 random_kthread() at random_kthread+0x270 pc = 0xc0147458 lr = 0xc02033f0 (fork_exit+0x88) sp = 0xdc20ce40 fp = 0xdc20ce58 r4 = 0xc2584c80 r5 = 0xc2582960 r6 = 0xc01471e8 r7 = 0x00000000 r8 = 0xdc20ce60 r9 = 0x00000000 r10 = 0x00000000 fork_exit() at fork_exit+0x88 pc = 0xc02033f0 lr = 0xc0475cec (fork_trampoline+0x14) sp = 0xdc20ce60 fp = 0x00000000 r4 = 0xc01471e8 r5 = 0x00000000 r6 = 0xc0c0c0c0 r7 = 0xc0c0c0c0 r8 = 0x00000000 fork_trampoline() at fork_trampoline+0x14 pc = 0xc0475cec lr = 0xc0475cec (fork_trampoline+0x14) sp = 0xdc20ce60 fp = 0x00000000 Unable to unwind further lock order reversal: 1st 0xc06f3c0c entropy harvest mutex (entropy harvest mutex) @ /usr/home/martin/Rasperry/head/sys/dev/random/randomdev_soft.c:242 2nd 0xc059198c sleepq chain (sleepq chain) @ /usr/home/martin/Rasperry/head/sys/kern/subr_sleepqueue.c:240 KDB: stack backtrace: db_trace_self() at db_trace_self pc = 0xc04652cc lr = 0xc012e474 (db_trace_self_wrapper+0x30) sp = 0xdc20cbf8 fp = 0xdc20cd10 r10 = 0xc06f3c0c db_trace_self_wrapper() at db_trace_self_wrapper+0x30 pc = 0xc012e474 lr = 0xc0268974 (kdb_backtrace+0x38) sp = 0xdc20cd18 fp = 0xdc20cd20 r4 = 0xc05908a4 r5 = 0xc04ba67d r6 = 0xc04bd04d r7 = 0xc049f1d4 kdb_backtrace() at kdb_backtrace+0x38 pc = 0xc0268974 lr = 0xc0282df8 (witness_checkorder+0xddc) sp = 0xdc20cd28 fp = 0xdc20cd78 r4 = 0xc04ba662 witness_checkorder() at witness_checkorder+0xddc pc = 0xc0282df8 lr = 0xc022050c (__mtx_lock_spin_flags+0xc4) sp = 0xdc20cd80 fp = 0xdc20cda0 r4 = 0x00000000 r5 = 0x00000000 r6 = 0xc059198c r7 = 0xc059199c r8 = 0x00000000 r9 = 0x000000f0 r10 = 0xc04ba67a __mtx_lock_spin_flags() at __mtx_lock_spin_flags+0xc4 pc = 0xc022050c lr = 0xc02751a4 (sleepq_lock+0x34) sp = 0xdc20cda8 fp = 0xdc20cda8 r4 = 0xc2582960 r5 = 0x00000000 r6 = 0xc0580394 r7 = 0x00000000 r8 = 0xc2584c80 r9 = 0x00000000 r10 = 0xc0580390 sleepq_lock() at sleepq_lock+0x34 pc = 0xc02751a4 lr = 0xc023c4c0 (msleep_spin_sbt+0x80) sp = 0xdc20cdb0 fp = 0xdc20cdf0 msleep_spin_sbt() at msleep_spin_sbt+0x80 pc = 0xc023c4c0 lr = 0xc0147458 (random_kthread+0x270) sp = 0xdc20cdf8 fp = 0xdc20ce38 r4 = 0xc06f3c1c r5 = 0x00000000 r6 = 0xc049f1d1 r7 = 0x00000000 r8 = 0x00000000 r9 = 0x00000000 r10 = 0xc0580390 random_kthread() at random_kthread+0x270 pc = 0xc0147458 lr = 0xc02033f0 (fork_exit+0x88) sp = 0xdc20ce40 fp = 0xdc20ce58 r4 = 0xc2584c80 r5 = 0xc2582960 r6 = 0xc01471e8 r7 = 0x00000000 r8 = 0xdc20ce60 r9 = 0x00000000 r10 = 0x00000000 fork_exit() at fork_exit+0x88 pc = 0xc02033f0 lr = 0xc0475cec (fork_trampoline+0x14) sp = 0xdc20ce60 fp = 0x00000000 r4 = 0xc01471e8 r5 = 0x00000000 r6 = 0xc0c0c0c0 r7 = 0xc0c0c0c0 r8 = 0x00000000 fork_trampoline() at fork_trampoline+0x14 pc = 0xc0475cec lr = 0xc0475cec (fork_trampoline+0x14) sp = 0xdc20ce60 fp = 0x00000000 Unable to unwind further usbus0: 480Mbps High Speed USB v2.0 ugen0.1: at usbus0 uhub0: on usbus0 mmcsd0: 8GB at mmc0 25.0MHz/4bit/65535-block WARNING: WITNESS option enabled, expect reduced performance. WARNING: DIAGNOSTIC option enabled, expect reduced performance. Root mount waiting for: usbus0 uhub0: 1 port with 1 removable, self powered ugen0.2: at usbus0 uhub1: on usbus0 uhub1: MTT enabled Root mount waiting for: usbus0 uhub1: 3 ports with 2 removable, self powered Root mount waiting for: usbus0 ugen0.3: at usbus0 smsc0: on usbus0 Trying to mount root from ufs:/dev/mmcsd0s2a [rw,noatime]... WARNING: / was not properly dismounted smsc0: chip 0xec00, rev. 0002 warning: no time-of-day clock registered, system time will not be set accurately miibus0: on smsc0 ukphy0: PHY 1 on miibus0 ukphy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto ue0: on smsc0 ue0: Ethernet address: b8:27:eb:1d:b7:5a Enlarging root partition mmcsd0s2 resized mmcsd0s2a resized super-block backups (for fsck -b #) at: Setting hostuuid: 0cff015d-0f73-11e3-b289-b827eb1db75a. Setting hostid: 0xe90281aa. No suitable dump device was found. Entropy harvesting: interrupts ethernet point_to_point U-Boot 2013.01-rc1-g6709570-dirty (Aug 17 2013 - 23:35:05) DRAM: 480 MiB WARNING: Caches not enabled MMC: bcm2835_sdhci: 0 Using default environment In: serial Out: lcd Err: lcd mbox: Timeout waiting for response bcm2835: Could not set USB power state Net: Net Initialization Skipped No ethernet found. Hit any key to stop autoboot: 3  2  1  0 reading uEnv.txt 89 bytes read in 9552 ms (0 Bytes/s) Importing environment from mmc ... reading ubldr 239540 bytes read in 54417 ms (3.9 KiB/s) ## Starting application at 0x02000054 ... Consoles: U-Boot console Compatible API signature found @1db682a8 Number of U-Boot devices: 1 FreeBSD/armv6 U-Boot loader, Revision 1.2 (martin@pcbsd-7130, Wed Aug 28 01:32:51 CEST 2013) DRAM: 480MB Device: disk |/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|Loading /boot/defaults/loader.conf /-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\/boot/kernel/kernel data=0x47b5e4+0x17e19c |/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|syms=[0x4+0x7fcb0/-\|/-\|/-\|/-\|+0x4+0x4d613/-\|/-\|/-] Hit [Enter] to boot immediately, or any other key for command prompt. Booting [/boot/kernel/kernel]... \|/-\|/Using DTB provided by U-Boot. Kernel entry at 0x100100... Kernel args: (null) 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-CURRENT #0 r254955M: Wed Aug 28 01:32:36 CEST 2013 martin@pcbsd-7130:/usr/home/martin/Rasperry/crochet-freebsd/work/obj/arm.armv6/usr/home/martin/Rasperry/head/sys/RPI-B arm FreeBSD clang version 3.3 (tags/RELEASE_33/final 183502) 20130610 WARNING: WITNESS option enabled, expect reduced performance. WARNING: DIAGNOSTIC option enabled, expect reduced performance. CPU: 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 = 536870912 (512 MB) avail memory = 482902016 (460 MB) random device not loaded; using insecure entropy 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 bcm_dma0: mem 0x20007000-0x20007fff,0x20e05000-0x20e05fff irq 24,25,26,27,28,29,30,31,32,33,34,35,36 on simplebus0 mbox0: mem 0x2000b880-0x2000b8bf irq 1 on simplebus0 sdhci_bcm0: mem 0x20300000-0x203000ff irq 70 on simplebus0 mmc0: on sdhci_bcm0 uart0: mem 0x20201000-0x20201fff irq 65 on simplebus0 uart0: console (115200,n,8,1) dwcotg0: mem 0x20980000-0x2099ffff irq 17 on simplebus0 usbus0 on dwcotg0 simplebus1: on fdtbus0 Timecounters tick every 10.000 msec lock order reversal: 1st 0xc06f3c0c entropy harvest mutex (entropy harvest mutex) @ /usr/home/martin/Rasperry/head/sys/dev/random/randomdev_soft.c:242 2nd 0xc25d7c20 uart_hwmtx (uart_hwmtx) @ /usr/home/martin/Rasperry/head/sys/dev/uart/uart_cpu.h:92 KDB: stack backtrace: db_trace_self() at db_trace_self pc = 0xc04652cc lr = 0xc012e474 (db_trace_self_wrapper+0x30) sp = 0xdc20c9c8 fp = 0xdc20cae0 r10 = 0xc06f3c0c db_trace_self_wrapper() at db_trace_self_wrapper+0x30 pc = 0xc012e474 lr = 0xc0268974 (kdb_backtrace+0x38) sp = 0xdc20cae8 fp = 0xdc20caf0 r4 = 0xc05908a4 r5 = 0xc049fb59 r6 = 0xc04bd04d r7 = 0xc049f1d4 kdb_backtrace() at kdb_backtrace+0x38 pc = 0xc0268974 lr = 0xc0282df8 (witness_checkorder+0xddc) sp = 0xdc20caf8 fp = 0xdc20cb48 r4 = 0xc049fa8a witness_checkorder() at witness_checkorder+0xddc pc = 0xc0282df8 lr = 0xc022050c (__mtx_lock_spin_flags+0xc4) sp = 0xdc20cb50 fp = 0xdc20cb70 r4 = 0x00000000 r5 = 0xc0580a84 r6 = 0xc25d7c20 r7 = 0xc25d7c30 r8 = 0x00000000 r9 = 0x0000005c r10 = 0xc049fb56 __mtx_lock_spin_flags() at __mtx_lock_spin_flags+0xc4 pc = 0xc022050c lr = 0xc014e9a4 (uart_cnputc+0x44) sp = 0xdc20cb78 fp = 0xdc20cb88 r4 = 0x0000006c r5 = 0xc0580a84 r6 = 0xc05908a0 r7 = 0xc0581700 r8 = 0xc055d590 r9 = 0xc05816e0 r10 = 0xdc20ccf0 uart_cnputc() at uart_cnputc+0x44 pc = 0xc014e9a4 lr = 0xc01eb6b0 (cnputc+0x80) sp = 0xdc20cb90 fp = 0xdc20cba8 r4 = 0x0000006c r5 = 0xc0551c30 r6 = 0xc05908a0 cnputc() at cnputc+0x80 pc = 0xc01eb6b0 lr = 0xc026e6ec (putchar+0x194) sp = 0xdc20cbb0 fp = 0xdc20cc18 r4 = 0x00000005 r5 = 0xdc20ccf0 r6 = 0x0000006c r7 = 0x00000000 r8 = 0xc06f52b4 r9 = 0xc026e558 putchar() at putchar+0x194 pc = 0xc026e6ec lr = 0xc026d53c (kvprintf+0xb0) sp = 0xdc20cc20 fp = 0xdc20ccd8 r4 = 0xc04bc4c4 r5 = 0x00000000 r6 = 0x00000000 r7 = 0x00000000 r8 = 0xc06f52b4 r9 = 0xc026e558 r10 = 0xdc20ccf0 kvprintf() at kvprintf+0xb0 pc = 0xc026d53c lr = 0xc026ec58 (printf+0x50) sp = 0xdc20cce0 fp = 0xdc20cd10 r4 = 0xc2446da8 r5 = 0xc2446a68 r6 = 0x00000000 r7 = 0xc06c394c r8 = 0xc06f52b4 r9 = 0x00000001 r10 = 0xc06c395b printf() at printf+0x50 pc = 0xc026ec58 lr = 0xc0282b58 (witness_checkorder+0xb3c) sp = 0xdc20cd28 fp = 0xdc20cd78 witness_checkorder() at witness_checkorder+0xb3c pc = 0xc0282b58 lr = 0xc022050c (__mtx_lock_spin_flags+0xc4) sp = 0xdc20cd80 fp = 0xdc20cda0 r4 = 0x00000000 r5 = 0x00000000 r6 = 0xc059198c r7 = 0xc059199c r8 = 0x00000000 r9 = 0x000000f0 r10 = 0xc04ba67a __mtx_lock_spin_flags() at __mtx_lock_spin_flags+0xc4 pc = 0xc022050c lr = 0xc02751a4 (sleepq_lock+0x34) sp = 0xdc20cda8 fp = 0xdc20cda8 r4 = 0xc2582960 r5 = 0x00000000 r6 = 0xc0580394 r7 = 0x00000000 r8 = 0xc2584c80 r9 = 0x00000000 r10 = 0xc0580390 sleepq_lock() at sleepq_lock+0x34 pc = 0xc02751a4 lr = 0xc023c4c0 (msleep_spin_sbt+0x80) sp = 0xdc20cdb0 fp = 0xdc20cdf0 msleep_spin_sbt() at msleep_spin_sbt+0x80 pc = 0xc023c4c0 lr = 0xc0147458 (random_kthread+0x270) sp = 0xdc20cdf8 fp = 0xdc20ce38 r4 = 0xc06f3c1c r5 = 0x00000000 r6 = 0xc049f1d1 r7 = 0x00000000 r8 = 0x00000000 r9 = 0x00000000 r10 = 0xc0580390 random_kthread() at random_kthread+0x270 pc = 0xc0147458 lr = 0xc02033f0 (fork_exit+0x88) sp = 0xdc20ce40 fp = 0xdc20ce58 r4 = 0xc2584c80 r5 = 0xc2582960 r6 = 0xc01471e8 r7 = 0x00000000 r8 = 0xdc20ce60 r9 = 0x00000000 r10 = 0x00000000 fork_exit() at fork_exit+0x88 pc = 0xc02033f0 lr = 0xc0475cec (fork_trampoline+0x14) sp = 0xdc20ce60 fp = 0x00000000 r4 = 0xc01471e8 r5 = 0x00000000 r6 = 0xc0c0c0c0 r7 = 0xc0c0c0c0 r8 = 0x00000000 fork_trampoline() at fork_trampoline+0x14 pc = 0xc0475cec lr = 0xc0475cec (fork_trampoline+0x14) sp = 0xdc20ce60 fp = 0x00000000 Unable to unwind further lock order reversal: 1st 0xc06f3c0c entropy harvest mutex (entropy harvest mutex) @ /usr/home/martin/Rasperry/head/sys/dev/random/randomdev_soft.c:242 2nd 0xc059198c sleepq chain (sleepq chain) @ /usr/home/martin/Rasperry/head/sys/kern/subr_sleepqueue.c:240 KDB: stack backtrace: db_trace_self() at db_trace_self pc = 0xc04652cc lr = 0xc012e474 (db_trace_self_wrapper+0x30) sp = 0xdc20cbf8 fp = 0xdc20cd10 r10 = 0xc06f3c0c db_trace_self_wrapper() at db_trace_self_wrapper+0x30 pc = 0xc012e474 lr = 0xc0268974 (kdb_backtrace+0x38) sp = 0xdc20cd18 fp = 0xdc20cd20 r4 = 0xc05908a4 r5 = 0xc04ba67d r6 = 0xc04bd04d r7 = 0xc049f1d4 kdb_backtrace() at kdb_backtrace+0x38 pc = 0xc0268974 lr = 0xc0282df8 (witness_checkorder+0xddc) sp = 0xdc20cd28 fp = 0xdc20cd78 r4 = 0xc04ba662 witness_checkorder() at witness_checkorder+0xddc pc = 0xc0282df8 lr = 0xc022050c (__mtx_lock_spin_flags+0xc4) sp = 0xdc20cd80 fp = 0xdc20cda0 r4 = 0x00000000 r5 = 0x00000000 r6 = 0xc059198c r7 = 0xc059199c r8 = 0x00000000 r9 = 0x000000f0 r10 = 0xc04ba67a __mtx_lock_spin_flags() at __mtx_lock_spin_flags+0xc4 pc = 0xc022050c lr = 0xc02751a4 (sleepq_lock+0x34) sp = 0xdc20cda8 fp = 0xdc20cda8 r4 = 0xc2582960 r5 = 0x00000000 r6 = 0xc0580394 r7 = 0x00000000 r8 = 0xc2584c80 r9 = 0x00000000 r10 = 0xc0580390 sleepq_lock() at sleepq_lock+0x34 pc = 0xc02751a4 lr = 0xc023c4c0 (msleep_spin_sbt+0x80) sp = 0xdc20cdb0 fp = 0xdc20cdf0 msleep_spin_sbt() at msleep_spin_sbt+0x80 pc = 0xc023c4c0 lr = 0xc0147458 (random_kthread+0x270) sp = 0xdc20cdf8 fp = 0xdc20ce38 r4 = 0xc06f3c1c r5 = 0x00000000 r6 = 0xc049f1d1 r7 = 0x00000000 r8 = 0x00000000 r9 = 0x00000000 r10 = 0xc0580390 random_kthread() at random_kthread+0x270 pc = 0xc0147458 lr = 0xc02033f0 (fork_exit+0x88) sp = 0xdc20ce40 fp = 0xdc20ce58 r4 = 0xc2584c80 r5 = 0xc2582960 r6 = 0xc01471e8 r7 = 0x00000000 r8 = 0xdc20ce60 r9 = 0x00000000 r10 = 0x00000000 fork_exit() at fork_exit+0x88 pc = 0xc02033f0 lr = 0xc0475cec (fork_trampoline+0x14) sp = 0xdc20ce60 fp = 0x00000000 r4 = 0xc01471e8 r5 = 0x00000000 r6 = 0xc0c0c0c0 r7 = 0xc0c0c0c0 r8 = 0x00000000 fork_trampoline() at fork_trampoline+0x14 pc = 0xc0475cec lr = 0xc0475cec (fork_trampoline+0x14) sp = 0xdc20ce60 fp = 0x00000000 Unable to unwind further usbus0: 480Mbps High Speed USB v2.0 ugen0.1: at usbus0 uhub0: on usbus0 mmcsd0: 8GB at mmc0 25.0MHz/4bit/65535-block WARNING: WITNESS option enabled, expect reduced performance. WARNING: DIAGNOSTIC option enabled, expect reduced performance. Root mount waiting for: usbus0 uhub0: 1 port with 1 removable, self powered Root mount waiting for: usbus0 ugen0.2: at usbus0 uhub1: on usbus0 uhub1: MTT enabled uhub1: 3 ports with 2 removable, self powered Root mount waiting for: usbus0 ugen0.3: at usbus0 smsc0: on usbus0 Trying to mount root from ufs:/dev/mmcsd0s2a [rw,noatime]... WARNING: / was not properly dismounted smsc0: chip 0xec00, rev. 0002 warning: no time-of-day clock registered, system time will not be set accurately miibus0: on smsc0 ukphy0: PHY 1 on miibus0 ukphy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto ue0: on smsc0 ue0: Ethernet address: b8:27:eb:1d:b7:5a Enlarging root partition mmcsd0s2 resized mmcsd0s2a resized super-block backups (for fsck -b #) at: Setting hostuuid: 27d85b91-0f73-11e3-b289-b827eb1db75a. Setting hostid: 0xaa3c183b. No suitable dump device was found. Entropy harvesting: interrupts ethernet point_to_point kickstart. Starting file system checks: ** SU+J Recovering /dev/mmcsd0s2a ** Reading 4194304 byte journal from inode 4. ** Building recovery table. ** Resolving unreferenced inode list. ** Processing journal entries. ** 28 journal records in 4096 bytes for 21.88% utilization ** Freed 0 inodes (0 dirs) 0 blocks, and 0 frags. ***** FILE SYSTEM MARKED CLEAN ***** Mounting local file systems:. Writing entropy file:. Setting hostname: raspberry-pi. smsc0: chip 0xec00, rev. 0002 ue0: link state changed to DOWN ue0: link state changed to UP Starting Network: lo0 ue0. lo0: flags=8049 metric 0 mtu 16384 options=600003 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1 inet 127.0.0.1 netmask 0xff000000 nd6 options=21 ue0: flags=8843 metric 0 mtu 1500 options=80001 ether b8:27:eb:1d:b7:5a media: Ethernet autoselect (100baseTX ) status: active nd6 options=29 Starting devd. Starting dhclient. DHCPDISCOVER on ue0 to 255.255.255.255 port 67 interval 7 DHCPOFFER from 192.168.1.250 DHCPREQUEST on ue0 to 255.255.255.255 port 67 DHCPACK from 192.168.1.250 bound to 192.168.1.54 -- renewal in 300 seconds. lock order reversal: (sleepable after non-sleepable) 1st 0xc2857d78 so_rcv (so_rcv) @ /usr/home/martin/Rasperry/head/sys/kern/uipc_socket.c:1594 2nd 0xc2899a30 vm map (user) (vm map (user)) @ /usr/home/martin/Rasperry/head/sys/vm/vm_map.c:3816 KDB: stack backtrace: db_trace_self() at db_trace_self pc = 0xc04652cc lr = 0xc012e474 (db_trace_self_wrapper+0x30) sp = 0xdd3ee818 fp = 0xdd3ee930 r10 = 0xc2857d78 db_trace_self_wrapper() at db_trace_self_wrapper+0x30 pc = 0xc012e474 lr = 0xc0268974 (kdb_backtrace+0x38) sp = 0xdd3ee938 fp = 0xdd3ee940 r4 = 0xc05908a4 r5 = 0xc04dce80 r6 = 0xc04bd04d r7 = 0xc04c14dc kdb_backtrace() at kdb_backtrace+0x38 pc = 0xc0268974 lr = 0xc0282df8 (witness_checkorder+0xddc) sp = 0xdd3ee948 fp = 0xdd3ee998 r4 = 0xc04bd221 witness_checkorder() at witness_checkorder+0xddc pc = 0xc0282df8 lr = 0xc023aaf0 (_sx_slock+0x84) sp = 0xdd3ee9a0 fp = 0xdd3ee9c8 r4 = 0x00000ee8 r5 = 0xc04dce7d r6 = 0xc2899a30 r7 = 0xc2899a40 r8 = 0x00000000 r9 = 0x00000000 r10 = 0xdd3eeb2c _sx_slock() at _sx_slock+0x84 pc = 0xc023aaf0 lr = 0xc044579c (vm_map_lookup+0x74) sp = 0xdd3ee9d0 fp = 0xdd3eea08 r4 = 0xc28999e0 r5 = 0xc04dce7d r6 = 0x3601a000 r7 = 0x3601a000 r8 = 0x00000002 vm_map_lookup() at vm_map_lookup+0x74 pc = 0xc044579c lr = 0xc0439a18 (vm_fault_hold+0xe4) sp = 0xdd3eea10 fp = 0xdd3eeb80 r4 = 0xc28999e0 r5 = 0x00000002 r6 = 0xc2819960 r7 = 0x3601a000 r8 = 0xdd3eeb10 r9 = 0x00000000 r10 = 0xc06f7af0 vm_fault_hold() at vm_fault_hold+0xe4 pc = 0xc0439a18 lr = 0xc04398ec (vm_fault+0x88) sp = 0xdd3eeb88 fp = 0xdd3eeba8 r4 = 0xc28999e0 r5 = 0x00000002 r6 = 0xc2819960 r7 = 0x3601a000 r8 = 0x00000000 r9 = 0x00000002 r10 = 0xc06f7af0 vm_fault() at vm_fault+0x88 pc = 0xc04398ec lr = 0xc04760fc (data_abort_handler+0x2a8) sp = 0xdd3eebb0 fp = 0xdd3eec50 r4 = 0xc2872640 r5 = 0xc2819960 r6 = 0xc04e30cc r7 = 0xc28726e8 r8 = 0xdd3eec58 r9 = 0xdd3eeeb0 r10 = 0xc28999e0 data_abort_handler() at data_abort_handler+0x2a8 pc = 0xc04760fc lr = 0xc0466b04 (exception_exit) sp = 0xdd3eec58 fp = 0xdd3eed10 r4 = 0xc056b1cc r5 = 0xc2857da4 r6 = 0xc2857d00 r7 = 0x3601a8c0 r8 = 0x00000000 r9 = 0xc2857d88 r10 = 0xc272fd00 exception_exit() at exception_exit pc = 0xc0466b04 lr = 0xc2819960 (0xc2819960) sp = 0xdd3eecac fp = 0xdd3eed10 r0 = 0x3601a8c0 r1 = 0xc272fb00 r2 = 0xc04c14d9 r3 = 0x000005ef r4 = 0xc056b1cc r5 = 0xc2857da4 r6 = 0xc2857d00 r7 = 0x3601a8c0 r8 = 0x00000000 r9 = 0xc2857d88 r10 = 0xc272fd00 r12 = 0x00000000 soreceive_generic() at soreceive_generic+0x4a8 pc = 0xc02a9aec lr = 0xc02ab784 (soreceive+0x2c) sp = 0xdd3eed18 fp = 0xdd3eed20 r4 = 0xc2819960 r5 = 0x00000000 r6 = 0xdd3eed98 r7 = 0x00000000 r8 = 0x00000006 r9 = 0xc27c5c40 r10 = 0x00000800 soreceive() at soreceive+0x2c pc = 0xc02ab784 lr = 0xc028da28 (soo_read+0x2c) sp = 0xdd3eed28 fp = 0xdd3eed30 soo_read() at soo_read+0x2c pc = 0xc028da28 lr = 0xc0286aa4 (dofileread+0xa8) sp = 0xdd3eed38 fp = 0xdd3eed58 dofileread() at dofileread+0xa8 pc = 0xc0286aa4 lr = 0xc0286764 (kern_readv+0x60) sp = 0xdd3eed60 fp = 0xdd3eed88 r4 = 0xffffffff r5 = 0x00000000 r6 = 0x00000000 r7 = 0x00000006 r8 = 0xdd3eed98 r9 = 0xc2819960 r10 = 0x2081f0f0 kern_readv() at kern_readv+0x60 pc = 0xc0286764 lr = 0xc02866f4 (sys_read+0x4c) sp = 0xdd3eed90 fp = 0xdd3eedb8 r4 = 0xc2819960 r5 = 0x00000000 r6 = 0xbfffe5a0 r7 = 0x00000000 r8 = 0xdd3eee10 r9 = 0xc2872640 sys_read() at sys_read+0x4c pc = 0xc02866f4 lr = 0xc0476bc4 (swi_handler+0x284) sp = 0xdd3eedc0 fp = 0xdd3eee58 swi_handler() at swi_handler+0x284 pc = 0xc0476bc4 lr = 0xc0466928 (swi_entry+0x2c) sp = 0xdd3eee60 fp = 0xbfffedc0 r4 = 0x000378f8 r5 = 0x0002d258 r6 = 0xbfffe5a0 r7 = 0x00000003 r8 = 0x00000000 r9 = 0x521d3af3 swi_entry() at swi_entry+0x2c pc = 0xc0466928 lr = 0xc0466928 (swi_entry+0x2c) sp = 0xdd3eee60 fp = 0xbfffedc0 Unable to unwind further vm_fault(0xc28999e0, 3601a000, 2, 0) -> 5 Fatal kernel mode data abort: 'Translation Fault (S)' trapframe: 0xdd3eec58 FSR=00000805, FAR=3601a8c4, spsr=20000013 r0 =3601a8c0, r1 =c272fb00, r2 =c04c14d9, r3 =000005ef r4 =c056b1cc, r5 =c2857da4, r6 =c2857d00, r7 =3601a8c0 r8 =00000000, r9 =c2857d88, r10=c272fd00, r11=dd3eed10 r12=00000000, ssp=dd3eeca8, slr=c2819960, pc =c02a9aec [ thread pid 542 tid 100059 ] Stopped at soreceive_generic+0x4a8: str r1, [r0, #0x004] db> >Release-Note: >Audit-Trail: >Unformatted: From owner-freebsd-arm@FreeBSD.ORG Wed Aug 28 05:51: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 C87FE704; Wed, 28 Aug 2013 05:51:16 +0000 (UTC) (envelope-from mailinglists@martinlaabs.de) Received: from relay01.alfahosting-server.de (relay01.alfahosting-server.de [109.237.142.236]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 868582C23; Wed, 28 Aug 2013 05:51:16 +0000 (UTC) Received: by relay01.alfahosting-server.de (Postfix, from userid 1001) id C24E532C1297; Wed, 28 Aug 2013 07:51:14 +0200 (CEST) X-Spam-DCC: : X-Spam-Level: X-Spam-Status: No, score=0.0 required=7.0 tests=BAYES_50 autolearn=disabled version=3.2.5 Received: from alfa3018.alfahosting-server.de (alfa3018.alfahosting-server.de [109.237.140.30]) by relay01.alfahosting-server.de (Postfix) with ESMTPS id 0F26732C17BE; Wed, 28 Aug 2013 07:51:12 +0200 (CEST) Received: from laabs.hf.ifn.et.tu-dresden.de (hfsync.ifn.et.tu-dresden.de [141.30.128.60]) by alfa3018.alfahosting-server.de (Postfix) with ESMTPSA id EB261515DE80; Wed, 28 Aug 2013 07:51:11 +0200 (CEST) Message-ID: <521D8FCF.3060204@martinlaabs.de> Date: Wed, 28 Aug 2013 07:51:11 +0200 From: Martin Laabs User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130809 Thunderbird/17.0.8 MIME-Version: 1.0 To: freebsd-arm Subject: Raspberry PI Kernel data abort Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Status: No X-Virus-Checker-Version: clamassassin 1.2.4 with ClamAV 0.97.3/17758/Wed Aug 28 04:36:35 2013 Cc: 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: Wed, 28 Aug 2013 05:51:16 -0000 Hi, Sporadically the raspberry pi fails to mount its root mmc card. After power off and power on again works most of the time. However there seem to be also configurations that fail permanently. Unfortunately I have no image of a sd card that fails on every boot. Do you have any idea how to get more information whats going wrong? For details and the full boot log have a look to: http://www.freebsd.org/cgi/query-pr.cgi?pr=181601 Best regards, Martin Laabs From owner-freebsd-arm@FreeBSD.ORG Wed Aug 28 05:57:53 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 0A5FFAA5; Wed, 28 Aug 2013 05:57:53 +0000 (UTC) (envelope-from mailinglists@martinlaabs.de) Received: from relay01.alfahosting-server.de (relay01.alfahosting-server.de [109.237.142.236]) by mx1.freebsd.org (Postfix) with ESMTP id 872532C5D; Wed, 28 Aug 2013 05:57:52 +0000 (UTC) Received: by relay01.alfahosting-server.de (Postfix, from userid 1001) id 796A932C146B; Wed, 28 Aug 2013 07:57:50 +0200 (CEST) X-Spam-DCC: : X-Spam-Level: X-Spam-Status: No, score=0.0 required=7.0 tests=BAYES_50 autolearn=disabled version=3.2.5 Received: from alfa3018.alfahosting-server.de (alfa3018.alfahosting-server.de [109.237.140.30]) by relay01.alfahosting-server.de (Postfix) with ESMTPS id 870B832C1401; Wed, 28 Aug 2013 07:57:48 +0200 (CEST) Received: from laabs.hf.ifn.et.tu-dresden.de (hfsync.ifn.et.tu-dresden.de [141.30.128.60]) by alfa3018.alfahosting-server.de (Postfix) with ESMTPSA id 75308515C0B1; Wed, 28 Aug 2013 07:57:48 +0200 (CEST) Message-ID: <521D915C.8040209@martinlaabs.de> Date: Wed, 28 Aug 2013 07:57:48 +0200 From: Martin Laabs User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130809 Thunderbird/17.0.8 MIME-Version: 1.0 To: freebsd-arm Subject: Re: Raspberry PI Kernel data abort References: <521D8FCF.3060204@martinlaabs.de> In-Reply-To: <521D8FCF.3060204@martinlaabs.de> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Status: No X-Virus-Checker-Version: clamassassin 1.2.4 with ClamAV 0.97.3/17758/Wed Aug 28 04:36:35 2013 Cc: 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: Wed, 28 Aug 2013 05:57:53 -0000 Sorry for the wrong subject. The problem with the data abort is another one that happens after DHCP address reception. The kernel is from my today nigh build from head (FreeBSD 10.0-CURRENT r254955). This problem might be related to the recent mbuf changes. The PR link is http://www.freebsd.org/cgi/query-pr.cgi?pr=181602 This is the log from my console: Mounting local file systems:. Writing entropy file:. Setting hostname: raspberry-pi. smsc0: chip 0xec00, rev. 0002 ue0: link state changed to DOWN ue0: link state changed to UP Starting Network: lo0 ue0. lo0: flags=8049 metric 0 mtu 16384 options=600003 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1 inet 127.0.0.1 netmask 0xff000000 nd6 options=21 ue0: flags=8843 metric 0 mtu 1500 options=80001 ether b8:27:eb:1d:b7:5a media: Ethernet autoselect (100baseTX ) status: active nd6 options=29 Starting devd. Starting dhclient. DHCPDISCOVER on ue0 to 255.255.255.255 port 67 interval 7 DHCPOFFER from 192.168.1.250 DHCPOFFER from 192.168.1.250 DHCPREQUEST on ue0 to 255.255.255.255 port 67 DHCPACK from 192.168.1.250 bound to 192.168.1.54 -- renewal in 300 seconds. lock order reversal: (sleepable after non-sleepable) 1st 0xc2857d78 so_rcv (so_rcv) @ /usr/home/martin/Rasperry/head/sys/kern/uipc_socket.c:1594 2nd 0xc2899a30 vm map (user) (vm map (user)) @ /usr/home/martin/Rasperry/head/sys/vm/vm_map.c:3816 KDB: stack backtrace: db_trace_self() at db_trace_self pc = 0xc04652cc lr = 0xc012e474 (db_trace_self_wrapper+0x30) sp = 0xdd3ee818 fp = 0xdd3ee930 r10 = 0xc2857d78 db_trace_self_wrapper() at db_trace_self_wrapper+0x30 pc = 0xc012e474 lr = 0xc0268974 (kdb_backtrace+0x38) sp = 0xdd3ee938 fp = 0xdd3ee940 r4 = 0xc05908a4 r5 = 0xc04dce80 r6 = 0xc04bd04d r7 = 0xc04c14dc kdb_backtrace() at kdb_backtrace+0x38 pc = 0xc0268974 lr = 0xc0282df8 (witness_checkorder+0xddc) sp = 0xdd3ee948 fp = 0xdd3ee998 r4 = 0xc04bd221 witness_checkorder() at witness_checkorder+0xddc pc = 0xc0282df8 lr = 0xc023aaf0 (_sx_slock+0x84) sp = 0xdd3ee9a0 fp = 0xdd3ee9c8 r4 = 0x00000ee8 r5 = 0xc04dce7d r6 = 0xc2899a30 r7 = 0xc2899a40 r8 = 0x00000000 r9 = 0x00000000 r10 = 0xdd3eeb2c _sx_slock() at _sx_slock+0x84 pc = 0xc023aaf0 lr = 0xc044579c (vm_map_lookup+0x74) sp = 0xdd3ee9d0 fp = 0xdd3eea08 r4 = 0xc28999e0 r5 = 0xc04dce7d r6 = 0x3601a000 r7 = 0x3601a000 r8 = 0x00000002 vm_map_lookup() at vm_map_lookup+0x74 pc = 0xc044579c lr = 0xc0439a18 (vm_fault_hold+0xe4) sp = 0xdd3eea10 fp = 0xdd3eeb80 r4 = 0xc28999e0 r5 = 0x00000002 r6 = 0xc2819960 r7 = 0x3601a000 r8 = 0xdd3eeb10 r9 = 0x00000000 r10 = 0xc06f7af0 vm_fault_hold() at vm_fault_hold+0xe4 pc = 0xc0439a18 lr = 0xc04398ec (vm_fault+0x88) sp = 0xdd3eeb88 fp = 0xdd3eeba8 r4 = 0xc28999e0 r5 = 0x00000002 r6 = 0xc2819960 r7 = 0x3601a000 r8 = 0x00000000 r9 = 0x00000002 r10 = 0xc06f7af0 vm_fault() at vm_fault+0x88 pc = 0xc04398ec lr = 0xc04760fc (data_abort_handler+0x2a8) sp = 0xdd3eebb0 fp = 0xdd3eec50 r4 = 0xc2872640 r5 = 0xc2819960 r6 = 0xc04e30cc r7 = 0xc28726e8 r8 = 0xdd3eec58 r9 = 0xdd3eeeb0 r10 = 0xc28999e0 data_abort_handler() at data_abort_handler+0x2a8 pc = 0xc04760fc lr = 0xc0466b04 (exception_exit) sp = 0xdd3eec58 fp = 0xdd3eed10 r4 = 0xc056b1cc r5 = 0xc2857da4 r6 = 0xc2857d00 r7 = 0x3601a8c0 r8 = 0x00000000 r9 = 0xc2857d88 r10 = 0xc272fd00 exception_exit() at exception_exit pc = 0xc0466b04 lr = 0xc2819960 (0xc2819960) sp = 0xdd3eecac fp = 0xdd3eed10 r0 = 0x3601a8c0 r1 = 0xc272fb00 r2 = 0xc04c14d9 r3 = 0x000005ef r4 = 0xc056b1cc r5 = 0xc2857da4 r6 = 0xc2857d00 r7 = 0x3601a8c0 r8 = 0x00000000 r9 = 0xc2857d88 r10 = 0xc272fd00 r12 = 0x00000000 soreceive_generic() at soreceive_generic+0x4a8 pc = 0xc02a9aec lr = 0xc02ab784 (soreceive+0x2c) sp = 0xdd3eed18 fp = 0xdd3eed20 r4 = 0xc2819960 r5 = 0x00000000 r6 = 0xdd3eed98 r7 = 0x00000000 r8 = 0x00000006 r9 = 0xc27c5c40 r10 = 0x00000800 soreceive() at soreceive+0x2c pc = 0xc02ab784 lr = 0xc028da28 (soo_read+0x2c) sp = 0xdd3eed28 fp = 0xdd3eed30 soo_read() at soo_read+0x2c pc = 0xc028da28 lr = 0xc0286aa4 (dofileread+0xa8) sp = 0xdd3eed38 fp = 0xdd3eed58 dofileread() at dofileread+0xa8 pc = 0xc0286aa4 lr = 0xc0286764 (kern_readv+0x60) sp = 0xdd3eed60 fp = 0xdd3eed88 r4 = 0xffffffff r5 = 0x00000000 r6 = 0x00000000 r7 = 0x00000006 r8 = 0xdd3eed98 r9 = 0xc2819960 r10 = 0x2081f0f0 kern_readv() at kern_readv+0x60 pc = 0xc0286764 lr = 0xc02866f4 (sys_read+0x4c) sp = 0xdd3eed90 fp = 0xdd3eedb8 r4 = 0xc2819960 r5 = 0x00000000 r6 = 0xbfffe5a0 r7 = 0x00000000 r8 = 0xdd3eee10 r9 = 0xc2872640 sys_read() at sys_read+0x4c pc = 0xc02866f4 lr = 0xc0476bc4 (swi_handler+0x284) sp = 0xdd3eedc0 fp = 0xdd3eee58 swi_handler() at swi_handler+0x284 pc = 0xc0476bc4 lr = 0xc0466928 (swi_entry+0x2c) sp = 0xdd3eee60 fp = 0xbfffedc0 r4 = 0x000378f8 r5 = 0x0002d258 r6 = 0xbfffe5a0 r7 = 0x00000003 r8 = 0x00000000 r9 = 0x521d3af3 swi_entry() at swi_entry+0x2c pc = 0xc0466928 lr = 0xc0466928 (swi_entry+0x2c) sp = 0xdd3eee60 fp = 0xbfffedc0 Unable to unwind further vm_fault(0xc28999e0, 3601a000, 2, 0) -> 5 Fatal kernel mode data abort: 'Translation Fault (S)' trapframe: 0xdd3eec58 FSR=00000805, FAR=3601a8c4, spsr=20000013 r0 =3601a8c0, r1 =c272fb00, r2 =c04c14d9, r3 =000005ef r4 =c056b1cc, r5 =c2857da4, r6 =c2857d00, r7 =3601a8c0 r8 =00000000, r9 =c2857d88, r10=c272fd00, r11=dd3eed10 r12=00000000, ssp=dd3eeca8, slr=c2819960, pc =c02a9aec [ thread pid 542 tid 100059 ] Stopped at soreceive_generic+0x4a8: str r1, [r0, #0x004] db> Best regards, Martin Laabs From owner-freebsd-arm@FreeBSD.ORG Wed Aug 28 06:16:03 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 C523A282; Wed, 28 Aug 2013 06:16:03 +0000 (UTC) (envelope-from mailinglists@martinlaabs.de) Received: from relay03.alfahosting-server.de (relay03.alfahosting-server.de [109.237.142.239]) by mx1.freebsd.org (Postfix) with ESMTP id 4D5432D4B; Wed, 28 Aug 2013 06:16:02 +0000 (UTC) Received: by relay03.alfahosting-server.de (Postfix, from userid 1001) id C1EB832C1391; Wed, 28 Aug 2013 08:03:57 +0200 (CEST) X-Spam-DCC: : X-Spam-Level: X-Spam-Status: No, score=0.0 required=7.0 tests=BAYES_50 autolearn=disabled version=3.2.5 Received: from alfa3018.alfahosting-server.de (alfa3018.alfahosting-server.de [109.237.140.30]) by relay03.alfahosting-server.de (Postfix) with ESMTPS id 93FFA32C15C2; Wed, 28 Aug 2013 08:03:54 +0200 (CEST) Received: from laabs.hf.ifn.et.tu-dresden.de (hfsync.ifn.et.tu-dresden.de [141.30.128.60]) by alfa3018.alfahosting-server.de (Postfix) with ESMTPSA id 69C7F515DE3D; Wed, 28 Aug 2013 08:03:54 +0200 (CEST) Message-ID: <521D92CA.8050008@martinlaabs.de> Date: Wed, 28 Aug 2013 08:03:54 +0200 From: Martin Laabs User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130809 Thunderbird/17.0.8 MIME-Version: 1.0 To: freebsd-arm Subject: Raspberry PI sporadically fails to mount mmc card Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Status: No X-Virus-Checker-Version: clamassassin 1.2.4 with ClamAV 0.97.3/17759/Wed Aug 28 06:44:22 2013 Cc: 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: Wed, 28 Aug 2013 06:16:03 -0000 Hi, Sporadically the raspberry pi fails to mount its root mmc card. After power off and power on again it works most of the time. However there seem to be also configurations that fail permanently. Unfortunately I have no image of a sd card that fails on every boot. Do you have any idea how to get more information whats going wrong? I think the problem starts after mmcsd0 received a timeout. Before that there are three lock reversals but I am not sure if they have any connection to the timeouts: lock order reversals before the timeout: 1st 0xc06f3c0c entropy harvest mutex (entropy harvest mutex) @ /usr/home/martin/Rasperry/head/sys/dev/random/randomdev_soft.c:242 2nd 0xc25d7c20 uart_hwmtx (uart_hwmtx) @ /usr/home/martin/Rasperry/head/sys/dev/uart/uart_cpu.h:92 1st 0xc06f3c0c entropy harvest mutex (entropy harvest mutex) @ /usr/home/martin/Rasperry/head/sys/dev/random/randomdev_soft.c:242 2nd 0xc059198c sleepq chain (sleepq chain) @ /usr/home/martin/Rasperry/head/sys/kern/subr_sleepqueue.c:240 1st 0xc06f3c0c entropy harvest mutex (entropy harvest mutex) @ /usr/home/martin/Rasperry/head/sys/dev/random/randomdev_soft.c:242 2nd 0xc059198c sleepq chain (sleepq chain) @ /usr/home/martin/Rasperry/head/sys/kern/subr_sleepqueue.c:240 [...] usbus0: 480Mbps High Speed USB v2.0 ugen0.1: at usbus0 uhub0: on usbus0 uhub0: 1 port with 1 removable, self powered mmcsd0: 8GB at mmc0 50.0MHz/4bit/65535-block WARNING: WITNESS option enabled, expect reduced performance. WARNING: DIAGNOSTIC option enabled, expect reduced performance. mmcsd0: Error indicated: 1 Timeout mmcsd0: Error indicated: 1 Timeout Root mount waiting for: usbus0 ugen0.2: at usbus0 uhub1: on usbus0 uhub1: MTT enabled Root mount waiting for: usbus0 uhub1: 3 ports with 2 removable, self powered Root mount waiting for: usbus0 ugen0.3: at usbus0 smsc0: on usbus0 Trying to mount root from ufs:/dev/mmcsd0s2a [rw,noatime]... mountroot: waiting for device /dev/mmcsd0s2a ... smsc0: chip 0xec00, rev. 0002 miibus0: on smsc0 ukphy0: PHY 1 on miibus0 ukphy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto ue0: on smsc0 ue0: Ethernet address: b8:27:eb:1d:b7:5a Mounting from ufs:/dev/mmcsd0s2a failed with error 19. Loader variables: vfs.root.mountfrom=ufs:/dev/mmcsd0s2a vfs.root.mountfrom.options=rw,noatime Manual root filesystem specification: : [options] Mount using filesystem and with the specified (optional) option list. eg. ufs:/dev/da0s1a zfs:tank cd9660:/dev/acd0 ro (which is equivalent to: mount -t cd9660 -o ro /dev/acd0 /) ? List valid disk boot devices . Yield 1 second (for background tasks) Abort manual input mountroot> For details and the full boot log have a look to: http://www.freebsd.org/cgi/query-pr.cgi?pr=181601 Best regards, Martin Laabs From owner-freebsd-arm@FreeBSD.ORG Wed Aug 28 12:20:01 2013 Return-Path: Delivered-To: freebsd-arm@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 646EDEA6 for ; Wed, 28 Aug 2013 12:20:01 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 4F4EE230F for ; Wed, 28 Aug 2013 12:20:01 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r7SCK10R091815 for ; Wed, 28 Aug 2013 12:20:01 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r7SCK07c091813; Wed, 28 Aug 2013 12:20:00 GMT (envelope-from gnats) Date: Wed, 28 Aug 2013 12:20:00 GMT Message-Id: <201308281220.r7SCK07c091813@freefall.freebsd.org> To: freebsd-arm@FreeBSD.org Cc: From: Ian Lepore Subject: Re: arm/181602: Raspberry PI kernel panic after DHCP X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Ian Lepore List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Aug 2013 12:20:01 -0000 The following reply was made to PR arm/181602; it has been noted by GNATS. From: Ian Lepore To: Martin Laabs Cc: freebsd-gnats-submit@FreeBSD.org Subject: Re: arm/181602: Raspberry PI kernel panic after DHCP Date: Wed, 28 Aug 2013 06:10:23 -0600 On Wed, 2013-08-28 at 05:44 +0000, Martin Laabs wrote: > >Number: 181602 > >Category: arm > >Synopsis: Raspberry PI kernel panic after DHCP > >Confidential: no > >Severity: non-critical > >Priority: low > >Responsible: freebsd-arm > >State: open > >Quarter: > >Keywords: > >Date-Required: > >Class: sw-bug > >Submitter-Id: current-users > >Arrival-Date: Wed Aug 28 05:50:00 UTC 2013 > >Closed-Date: > >Last-Modified: > >Originator: Martin Laabs > >Release: FreeBSD 10.0-CURRENT #0 r254955M > >Organization: > - > >Environment: > not available > >Description: > With the current r254955M build the kernel panics after receiving the DHCP answer. Currently I do not know whether this is directly related to network or is the following task in the init process. The full boot log is attached. > It might be also in context with the lock order reversal: > > DHCPOFFER from 192.168.1.250 > DHCPREQUEST on ue0 to 255.255.255.255 port 67 > DHCPACK from 192.168.1.250 > bound to 192.168.1.54 -- renewal in 300 seconds. > lock order reversal: (sleepable after non-sleepable) > 1st 0xc2857d78 so_rcv (so_rcv) @ /usr/home/martin/Rasperry/head/sys/kern/uipc_socket.c:1594 > 2nd 0xc2899a30 vm map (user) (vm map (user)) @ /usr/home/martin/Rasperry/head/sys/vm/vm_map.c:3816 > KDB: stack backtrace: > db_trace_self() at db_trace_self > pc = 0xc04652cc lr = 0xc012e474 (db_trace_self_wrapper+0x30) > sp = 0xdd3ee818 fp = 0xdd3ee930 > r10 = 0xc2857d78 > db_trace_self_wrapper() at db_trace_self_wrapper+0x30 > pc = 0xc012e474 lr = 0xc0268974 (kdb_backtrace+0x38) > sp = 0xdd3ee938 fp = 0xdd3ee940 > r4 = 0xc05908a4 r5 = 0xc04dce80 > r6 = 0xc04bd04d r7 = 0xc04c14dc > kdb_backtrace() at kdb_backtrace+0x38 > pc = 0xc0268974 lr = 0xc0282df8 (witness_checkorder+0xddc) > sp = 0xdd3ee948 fp = 0xdd3ee998 > r4 = 0xc04bd221 > witness_checkorder() at witness_checkorder+0xddc > pc = 0xc0282df8 lr = 0xc023aaf0 (_sx_slock+0x84) > sp = 0xdd3ee9a0 fp = 0xdd3ee9c8 > r4 = 0x00000ee8 r5 = 0xc04dce7d > r6 = 0xc2899a30 r7 = 0xc2899a40 > r8 = 0x00000000 r9 = 0x00000000 > r10 = 0xdd3eeb2c > _sx_slock() at _sx_slock+0x84 > pc = 0xc023aaf0 lr = 0xc044579c (vm_map_lookup+0x74) > sp = 0xdd3ee9d0 fp = 0xdd3eea08 > r4 = 0xc28999e0 r5 = 0xc04dce7d > r6 = 0x3601a000 r7 = 0x3601a000 > r8 = 0x00000002 > vm_map_lookup() at vm_map_lookup+0x74 > pc = 0xc044579c lr = 0xc0439a18 (vm_fault_hold+0xe4) > sp = 0xdd3eea10 fp = 0xdd3eeb80 > r4 = 0xc28999e0 r5 = 0x00000002 > r6 = 0xc2819960 r7 = 0x3601a000 > r8 = 0xdd3eeb10 r9 = 0x00000000 > r10 = 0xc06f7af0 > vm_fault_hold() at vm_fault_hold+0xe4 > pc = 0xc0439a18 lr = 0xc04398ec (vm_fault+0x88) > sp = 0xdd3eeb88 fp = 0xdd3eeba8 > r4 = 0xc28999e0 r5 = 0x00000002 > r6 = 0xc2819960 r7 = 0x3601a000 > r8 = 0x00000000 r9 = 0x00000002 > r10 = 0xc06f7af0 > vm_fault() at vm_fault+0x88 > pc = 0xc04398ec lr = 0xc04760fc (data_abort_handler+0x2a8) > sp = 0xdd3eebb0 fp = 0xdd3eec50 > r4 = 0xc2872640 r5 = 0xc2819960 > r6 = 0xc04e30cc r7 = 0xc28726e8 > r8 = 0xdd3eec58 r9 = 0xdd3eeeb0 > r10 = 0xc28999e0 > data_abort_handler() at data_abort_handler+0x2a8 > pc = 0xc04760fc lr = 0xc0466b04 (exception_exit) > sp = 0xdd3eec58 fp = 0xdd3eed10 > r4 = 0xc056b1cc r5 = 0xc2857da4 > r6 = 0xc2857d00 r7 = 0x3601a8c0 > r8 = 0x00000000 r9 = 0xc2857d88 > r10 = 0xc272fd00 > exception_exit() at exception_exit > pc = 0xc0466b04 lr = 0xc2819960 (0xc2819960) > sp = 0xdd3eecac fp = 0xdd3eed10 > r0 = 0x3601a8c0 r1 = 0xc272fb00 > r2 = 0xc04c14d9 r3 = 0x000005ef > r4 = 0xc056b1cc r5 = 0xc2857da4 > r6 = 0xc2857d00 r7 = 0x3601a8c0 > r8 = 0x00000000 r9 = 0xc2857d88 > r10 = 0xc272fd00 r12 = 0x00000000 > soreceive_generic() at soreceive_generic+0x4a8 > pc = 0xc02a9aec lr = 0xc02ab784 (soreceive+0x2c) > sp = 0xdd3eed18 fp = 0xdd3eed20 > r4 = 0xc2819960 r5 = 0x00000000 > r6 = 0xdd3eed98 r7 = 0x00000000 > r8 = 0x00000006 r9 = 0xc27c5c40 > r10 = 0x00000800 > soreceive() at soreceive+0x2c > pc = 0xc02ab784 lr = 0xc028da28 (soo_read+0x2c) > sp = 0xdd3eed28 fp = 0xdd3eed30 > soo_read() at soo_read+0x2c > pc = 0xc028da28 lr = 0xc0286aa4 (dofileread+0xa8) > sp = 0xdd3eed38 fp = 0xdd3eed58 > dofileread() at dofileread+0xa8 > pc = 0xc0286aa4 lr = 0xc0286764 (kern_readv+0x60) > sp = 0xdd3eed60 fp = 0xdd3eed88 > r4 = 0xffffffff r5 = 0x00000000 > r6 = 0x00000000 r7 = 0x00000006 > r8 = 0xdd3eed98 r9 = 0xc2819960 > r10 = 0x2081f0f0 > kern_readv() at kern_readv+0x60 > pc = 0xc0286764 lr = 0xc02866f4 (sys_read+0x4c) > sp = 0xdd3eed90 fp = 0xdd3eedb8 > r4 = 0xc2819960 r5 = 0x00000000 > r6 = 0xbfffe5a0 r7 = 0x00000000 > r8 = 0xdd3eee10 r9 = 0xc2872640 > sys_read() at sys_read+0x4c > pc = 0xc02866f4 lr = 0xc0476bc4 (swi_handler+0x284) > sp = 0xdd3eedc0 fp = 0xdd3eee58 > swi_handler() at swi_handler+0x284 > pc = 0xc0476bc4 lr = 0xc0466928 (swi_entry+0x2c) > sp = 0xdd3eee60 fp = 0xbfffedc0 > r4 = 0x000378f8 r5 = 0x0002d258 > r6 = 0xbfffe5a0 r7 = 0x00000003 > r8 = 0x00000000 r9 = 0x521d3af3 > swi_entry() at swi_entry+0x2c > pc = 0xc0466928 lr = 0xc0466928 (swi_entry+0x2c) > sp = 0xdd3eee60 fp = 0xbfffedc0 > Unable to unwind further > > vm_fault(0xc28999e0, 3601a000, 2, 0) -> 5 > Fatal kernel mode data abort: 'Translation Fault (S)' > trapframe: 0xdd3eec58 > FSR=00000805, FAR=3601a8c4, spsr=20000013 > r0 =3601a8c0, r1 =c272fb00, r2 =c04c14d9, r3 =000005ef > r4 =c056b1cc, r5 =c2857da4, r6 =c2857d00, r7 =3601a8c0 > r8 =00000000, r9 =c2857d88, r10=c272fd00, r11=dd3eed10 > r12=00000000, ssp=dd3eeca8, slr=c2819960, pc =c02a9aec > > [ thread pid 542 tid 100059 ] > Stopped at soreceive_generic+0x4a8: str r1, [r0, #0x004] > db> > > >How-To-Repeat: > Build current for Rasperry Pi and run > >Fix: > > > Patch attached with submission follows: > > > > U-Boot 2013.01-rc1-g6709570-dirty (Aug 17 2013 - 23:35:05) > > DRAM: 480 MiB > WARNING: Caches not enabled > MMC: bcm2835_sdhci: 0 > Using default environment > > In: serial > Out: lcd > Err: lcd > mbox: Timeout waiting for response > bcm2835: Could not set USB power state > Net: Net Initialization Skipped > No ethernet found. > Hit any key to stop autoboot: 3  2  1  0 > reading uEnv.txt > 89 bytes read in 9541 ms (0 Bytes/s) > Importing environment from mmc ... > reading ubldr > 239540 bytes read in 54396 ms (3.9 KiB/s) > ## Starting application at 0x02000054 ... > Consoles: U-Boot console > Compatible API signature found @1db682a8 > Number of U-Boot devices: 1 > > FreeBSD/armv6 U-Boot loader, Revision 1.2 > (martin@pcbsd-7130, Wed Aug 28 01:32:51 CEST 2013) > DRAM: 480MB > > Device: disk > |/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|Loading /boot/defaults/loader.conf > /-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\/boot/kernel/kernel data=0x47b5e4+0x17e19c |/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|syms=[0x4+0x7fcb0/-\|/-\|/-\|/-\|+0x4+0x4d 613/-\|/-\|/-] > > Hit [Enter] to boot immediately, or any other key for command prompt. > Booting [/boot/kernel/kernel]... > \|/-\|/Using DTB provided by U-Boot. > Kernel entry at 0x100100... > Kernel args: (null) > 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-CURRENT #0 r254955M: Wed Aug 28 01:32:36 CEST 2013 > martin@pcbsd-7130:/usr/home/martin/Rasperry/crochet-freebsd/work/obj/arm.armv6/usr/home/martin/Rasperry/head/sys/RPI-B arm > FreeBSD clang version 3.3 (tags/RELEASE_33/final 183502) 20130610 > WARNING: WITNESS option enabled, expect reduced performance. > WARNING: DIAGNOSTIC option enabled, expect reduced performance. > CPU: 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 = 536870912 (512 MB) > avail memory = 482902016 (460 MB) > random device not loaded; using insecure entropy > 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 > bcm_dma0: mem 0x20007000-0x20007fff,0x20e05000-0x20e05fff irq 24,25,26,27,28,29,30,31,32,33,34,35,36 on simplebus0 > mbox0: mem 0x2000b880-0x2000b8bf irq 1 on simplebus0 > sdhci_bcm0: mem 0x20300000-0x203000ff irq 70 on simplebus0 > mmc0: on sdhci_bcm0 > uart0: mem 0x20201000-0x20201fff irq 65 on simplebus0 > uart0: console (115200,n,8,1) > dwcotg0: mem 0x20980000-0x2099ffff irq 17 on simplebus0 > usbus0 on dwcotg0 > simplebus1: on fdtbus0 > Timecounters tick every 10.000 msec > lock order reversal: > 1st 0xc06f3c0c entropy harvest mutex (entropy harvest mutex) @ /usr/home/martin/Rasperry/head/sys/dev/random/randomdev_soft.c:242 > 2nd 0xc25d7c20 uart_hwmtx (uart_hwmtx) @ /usr/home/martin/Rasperry/head/sys/dev/uart/uart_cpu.h:92 > KDB: stack backtrace: > db_trace_self() at db_trace_self > pc = 0xc04652cc lr = 0xc012e474 (db_trace_self_wrapper+0x30) > sp = 0xdc20c9c8 fp = 0xdc20cae0 > r10 = 0xc06f3c0c > db_trace_self_wrapper() at db_trace_self_wrapper+0x30 > pc = 0xc012e474 lr = 0xc0268974 (kdb_backtrace+0x38) > sp = 0xdc20cae8 fp = 0xdc20caf0 > r4 = 0xc05908a4 r5 = 0xc049fb59 > r6 = 0xc04bd04d r7 = 0xc049f1d4 > kdb_backtrace() at kdb_backtrace+0x38 > pc = 0xc0268974 lr = 0xc0282df8 (witness_checkorder+0xddc) > sp = 0xdc20caf8 fp = 0xdc20cb48 > r4 = 0xc049fa8a > witness_checkorder() at witness_checkorder+0xddc > pc = 0xc0282df8 lr = 0xc022050c (__mtx_lock_spin_flags+0xc4) > sp = 0xdc20cb50 fp = 0xdc20cb70 > r4 = 0x00000000 r5 = 0xc0580a84 > r6 = 0xc25d7c20 r7 = 0xc25d7c30 > r8 = 0x00000000 r9 = 0x0000005c > r10 = 0xc049fb56 > __mtx_lock_spin_flags() at __mtx_lock_spin_flags+0xc4 > pc = 0xc022050c lr = 0xc014e9a4 (uart_cnputc+0x44) > sp = 0xdc20cb78 fp = 0xdc20cb88 > r4 = 0x0000006c r5 = 0xc0580a84 > r6 = 0xc05908a0 r7 = 0xc0581700 > r8 = 0xc055d590 r9 = 0xc05816e0 > r10 = 0xdc20ccf0 > uart_cnputc() at uart_cnputc+0x44 > pc = 0xc014e9a4 lr = 0xc01eb6b0 (cnputc+0x80) > sp = 0xdc20cb90 fp = 0xdc20cba8 > r4 = 0x0000006c r5 = 0xc0551c30 > r6 = 0xc05908a0 > cnputc() at cnputc+0x80 > pc = 0xc01eb6b0 lr = 0xc026e6ec (putchar+0x194) > sp = 0xdc20cbb0 fp = 0xdc20cc18 > r4 = 0x00000005 r5 = 0xdc20ccf0 > r6 = 0x0000006c r7 = 0x00000000 > r8 = 0xc06f52b4 r9 = 0xc026e558 > putchar() at putchar+0x194 > pc = 0xc026e6ec lr = 0xc026d53c (kvprintf+0xb0) > sp = 0xdc20cc20 fp = 0xdc20ccd8 > r4 = 0xc04bc4c4 r5 = 0x00000000 > r6 = 0x00000000 r7 = 0x00000000 > r8 = 0xc06f52b4 r9 = 0xc026e558 > r10 = 0xdc20ccf0 > kvprintf() at kvprintf+0xb0 > pc = 0xc026d53c lr = 0xc026ec58 (printf+0x50) > sp = 0xdc20cce0 fp = 0xdc20cd10 > r4 = 0xc2446da8 r5 = 0xc2446a68 > r6 = 0x00000000 r7 = 0xc06c394c > r8 = 0xc06f52b4 r9 = 0x00000001 > r10 = 0xc06c395b > printf() at printf+0x50 > pc = 0xc026ec58 lr = 0xc0282b58 (witness_checkorder+0xb3c) > sp = 0xdc20cd28 fp = 0xdc20cd78 > witness_checkorder() at witness_checkorder+0xb3c > pc = 0xc0282b58 lr = 0xc022050c (__mtx_lock_spin_flags+0xc4) > sp = 0xdc20cd80 fp = 0xdc20cda0 > r4 = 0x00000000 r5 = 0x00000000 > r6 = 0xc059198c r7 = 0xc059199c > r8 = 0x00000000 r9 = 0x000000f0 > r10 = 0xc04ba67a > __mtx_lock_spin_flags() at __mtx_lock_spin_flags+0xc4 > pc = 0xc022050c lr = 0xc02751a4 (sleepq_lock+0x34) > sp = 0xdc20cda8 fp = 0xdc20cda8 > r4 = 0xc2582960 r5 = 0x00000000 > r6 = 0xc0580394 r7 = 0x00000000 > r8 = 0xc2584c80 r9 = 0x00000000 > r10 = 0xc0580390 > sleepq_lock() at sleepq_lock+0x34 > pc = 0xc02751a4 lr = 0xc023c4c0 (msleep_spin_sbt+0x80) > sp = 0xdc20cdb0 fp = 0xdc20cdf0 > msleep_spin_sbt() at msleep_spin_sbt+0x80 > pc = 0xc023c4c0 lr = 0xc0147458 (random_kthread+0x270) > sp = 0xdc20cdf8 fp = 0xdc20ce38 > r4 = 0xc06f3c1c r5 = 0x00000000 > r6 = 0xc049f1d1 r7 = 0x00000000 > r8 = 0x00000000 r9 = 0x00000000 > r10 = 0xc0580390 > random_kthread() at random_kthread+0x270 > pc = 0xc0147458 lr = 0xc02033f0 (fork_exit+0x88) > sp = 0xdc20ce40 fp = 0xdc20ce58 > r4 = 0xc2584c80 r5 = 0xc2582960 > r6 = 0xc01471e8 r7 = 0x00000000 > r8 = 0xdc20ce60 r9 = 0x00000000 > r10 = 0x00000000 > fork_exit() at fork_exit+0x88 > pc = 0xc02033f0 lr = 0xc0475cec (fork_trampoline+0x14) > sp = 0xdc20ce60 fp = 0x00000000 > r4 = 0xc01471e8 r5 = 0x00000000 > r6 = 0xc0c0c0c0 r7 = 0xc0c0c0c0 > r8 = 0x00000000 > fork_trampoline() at fork_trampoline+0x14 > pc = 0xc0475cec lr = 0xc0475cec (fork_trampoline+0x14) > sp = 0xdc20ce60 fp = 0x00000000 > Unable to unwind further > lock order reversal: > 1st 0xc06f3c0c entropy harvest mutex (entropy harvest mutex) @ /usr/home/martin/Rasperry/head/sys/dev/random/randomdev_soft.c:242 > 2nd 0xc059198c sleepq chain (sleepq chain) @ /usr/home/martin/Rasperry/head/sys/kern/subr_sleepqueue.c:240 > KDB: stack backtrace: > db_trace_self() at db_trace_self > pc = 0xc04652cc lr = 0xc012e474 (db_trace_self_wrapper+0x30) > sp = 0xdc20cbf8 fp = 0xdc20cd10 > r10 = 0xc06f3c0c > db_trace_self_wrapper() at db_trace_self_wrapper+0x30 > pc = 0xc012e474 lr = 0xc0268974 (kdb_backtrace+0x38) > sp = 0xdc20cd18 fp = 0xdc20cd20 > r4 = 0xc05908a4 r5 = 0xc04ba67d > r6 = 0xc04bd04d r7 = 0xc049f1d4 > kdb_backtrace() at kdb_backtrace+0x38 > pc = 0xc0268974 lr = 0xc0282df8 (witness_checkorder+0xddc) > sp = 0xdc20cd28 fp = 0xdc20cd78 > r4 = 0xc04ba662 > witness_checkorder() at witness_checkorder+0xddc > pc = 0xc0282df8 lr = 0xc022050c (__mtx_lock_spin_flags+0xc4) > sp = 0xdc20cd80 fp = 0xdc20cda0 > r4 = 0x00000000 r5 = 0x00000000 > r6 = 0xc059198c r7 = 0xc059199c > r8 = 0x00000000 r9 = 0x000000f0 > r10 = 0xc04ba67a > __mtx_lock_spin_flags() at __mtx_lock_spin_flags+0xc4 > pc = 0xc022050c lr = 0xc02751a4 (sleepq_lock+0x34) > sp = 0xdc20cda8 fp = 0xdc20cda8 > r4 = 0xc2582960 r5 = 0x00000000 > r6 = 0xc0580394 r7 = 0x00000000 > r8 = 0xc2584c80 r9 = 0x00000000 > r10 = 0xc0580390 > sleepq_lock() at sleepq_lock+0x34 > pc = 0xc02751a4 lr = 0xc023c4c0 (msleep_spin_sbt+0x80) > sp = 0xdc20cdb0 fp = 0xdc20cdf0 > msleep_spin_sbt() at msleep_spin_sbt+0x80 > pc = 0xc023c4c0 lr = 0xc0147458 (random_kthread+0x270) > sp = 0xdc20cdf8 fp = 0xdc20ce38 > r4 = 0xc06f3c1c r5 = 0x00000000 > r6 = 0xc049f1d1 r7 = 0x00000000 > r8 = 0x00000000 r9 = 0x00000000 > r10 = 0xc0580390 > random_kthread() at random_kthread+0x270 > pc = 0xc0147458 lr = 0xc02033f0 (fork_exit+0x88) > sp = 0xdc20ce40 fp = 0xdc20ce58 > r4 = 0xc2584c80 r5 = 0xc2582960 > r6 = 0xc01471e8 r7 = 0x00000000 > r8 = 0xdc20ce60 r9 = 0x00000000 > r10 = 0x00000000 > fork_exit() at fork_exit+0x88 > pc = 0xc02033f0 lr = 0xc0475cec (fork_trampoline+0x14) > sp = 0xdc20ce60 fp = 0x00000000 > r4 = 0xc01471e8 r5 = 0x00000000 > r6 = 0xc0c0c0c0 r7 = 0xc0c0c0c0 > r8 = 0x00000000 > fork_trampoline() at fork_trampoline+0x14 > pc = 0xc0475cec lr = 0xc0475cec (fork_trampoline+0x14) > sp = 0xdc20ce60 fp = 0x00000000 > Unable to unwind further > usbus0: 480Mbps High Speed USB v2.0 > ugen0.1: at usbus0 > uhub0: on usbus0 > uhub0: 1 port with 1 removable, self powered > mmcsd0: 8GB at mmc0 50.0MHz/4bit/65535-block > WARNING: WITNESS option enabled, expect reduced performance. > WARNING: DIAGNOSTIC option enabled, expect reduced performance. > mmcsd0: Error indicated: 1 Timeout > mmcsd0: Error indicated: 1 Timeout > Root mount waiting for: usbus0 > ugen0.2: at usbus0 > uhub1: on usbus0 > uhub1: MTT enabled > Root mount waiting for: usbus0 > uhub1: 3 ports with 2 removable, self powered > Root mount waiting for: usbus0 > ugen0.3: at usbus0 > smsc0: on usbus0 > Trying to mount root from ufs:/dev/mmcsd0s2a [rw,noatime]... > mountroot: waiting for device /dev/mmcsd0s2a ... > smsc0: chip 0xec00, rev. 0002 > miibus0: on smsc0 > ukphy0: PHY 1 on miibus0 > ukphy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto > ue0: on smsc0 > ue0: Ethernet address: b8:27:eb:1d:b7:5a > Mounting from ufs:/dev/mmcsd0s2a failed with error 19. > > Loader variables: > vfs.root.mountfrom=ufs:/dev/mmcsd0s2a > vfs.root.mountfrom.options=rw,noatime > > Manual root filesystem specification: > : [options] > Mount using filesystem > and with the specified (optional) option list. > > eg. ufs:/dev/da0s1a > zfs:tank > cd9660:/dev/acd0 ro > (which is equivalent to: mount -t cd9660 -o ro /dev/acd0 /) > > ? List valid disk boot devices > . Yield 1 second (for background tasks) > Abort manual input > > mountroot> kickstart. > Starting file system checks: > ** SU+J Recovering /dev/mmcsd0s2a > ** Reading 4194304 byte journal from inode 4. > ** Building recovery table. > ** Resolving unreferenced inode list. > ** Processing journal entries. > ** 31 journal records in 4608 bytes for 21.53% utilization > ** Freed 0 inodes (0 dirs) 0 blocks, and 0 frags. > > ***** FILE SYSTEM MARKED CLEAN ***** > Mounting local file systems:. > Writing entropy file:. > Setting hostname: raspberry-pi. > smsc0: chip 0xec00, rev. 0002 > ue0: link state changed to DOWN > ue0: link state changed to UP > Starting Network: lo0 ue0. > lo0: flags=8049 metric 0 mtu 16384 > options=600003 > inet6 ::1 prefixlen 128 > inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1 > inet 127.0.0.1 netmask 0xff000000 > nd6 options=21 > ue0: flags=8843 metric 0 mtu 1500 > options=80001 > ether b8:27:eb:1d:b7:5a > media: Ethernet autoselect (100baseTX ) > status: active > nd6 options=29 > Starting devd. > Starting dhclient. > DHCPDISCOVER on ue0 to 255.255.255.255 port 67 interval 4 > DHCPOFFER from 192.168.1.250 > DHCPREQUEST on ue0 to 255.255.255.255 port 67 > DHCPACK from 192.168.1.250 > bound to 192.168.1.54 -- renewal in 300 seconds. > lock order reversal: (sleepable after non-sleepable) > 1st 0xc2857d78 so_rcv (so_rcv) @ /usr/home/martin/Rasperry/head/sys/kern/uipc_socket.c:1594 > 2nd 0xc2898a30 vm map (user) (vm map (user)) @ /usr/home/martin/Rasperry/head/sys/vm/vm_map.c:3816 > KDB: stack backtrace: > db_trace_self() at db_trace_self > pc = 0xc04652cc lr = 0xc012e474 (db_trace_self_wrapper+0x30) > sp = 0xdd3ee818 fp = 0xdd3ee930 > r10 = 0xc2857d78 > db_trace_self_wrapper() at db_trace_self_wrapper+0x30 > pc = 0xc012e474 lr = 0xc0268974 (kdb_backtrace+0x38) > sp = 0xdd3ee938 fp = 0xdd3ee940 > r4 = 0xc05908a4 r5 = 0xc04dce80 > r6 = 0xc04bd04d r7 = 0xc04c14dc > kdb_backtrace() at kdb_backtrace+0x38 > pc = 0xc0268974 lr = 0xc0282df8 (witness_checkorder+0xddc) > sp = 0xdd3ee948 fp = 0xdd3ee998 > r4 = 0xc04bd221 > witness_checkorder() at witness_checkorder+0xddc > pc = 0xc0282df8 lr = 0xc023aaf0 (_sx_slock+0x84) > sp = 0xdd3ee9a0 fp = 0xdd3ee9c8 > r4 = 0x00000ee8 r5 = 0xc04dce7d > r6 = 0xc2898a30 r7 = 0xc2898a40 > r8 = 0x00000000 r9 = 0x00000000 > r10 = 0xdd3eeb2c > _sx_slock() at _sx_slock+0x84 > pc = 0xc023aaf0 lr = 0xc044579c (vm_map_lookup+0x74) > sp = 0xdd3ee9d0 fp = 0xdd3eea08 > r4 = 0xc28989e0 r5 = 0xc04dce7d > r6 = 0x3601a000 r7 = 0x3601a000 > r8 = 0x00000002 > vm_map_lookup() at vm_map_lookup+0x74 > pc = 0xc044579c lr = 0xc0439a18 (vm_fault_hold+0xe4) > sp = 0xdd3eea10 fp = 0xdd3eeb80 > r4 = 0xc28989e0 r5 = 0x00000002 > r6 = 0xc2819960 r7 = 0x3601a000 > r8 = 0xdd3eeb10 r9 = 0x00000000 > r10 = 0xc06f7af0 > vm_fault_hold() at vm_fault_hold+0xe4 > pc = 0xc0439a18 lr = 0xc04398ec (vm_fault+0x88) > sp = 0xdd3eeb88 fp = 0xdd3eeba8 > r4 = 0xc28989e0 r5 = 0x00000002 > r6 = 0xc2819960 r7 = 0x3601a000 > r8 = 0x00000000 r9 = 0x00000002 > r10 = 0xc06f7af0 > vm_fault() at vm_fault+0x88 > pc = 0xc04398ec lr = 0xc04760fc (data_abort_handler+0x2a8) > sp = 0xdd3eebb0 fp = 0xdd3eec50 > r4 = 0xc2872640 r5 = 0xc2819960 > r6 = 0xc04e30cc r7 = 0xc28726e8 > r8 = 0xdd3eec58 r9 = 0xdd3eeeb0 > r10 = 0xc28989e0 > data_abort_handler() at data_abort_handler+0x2a8 > pc = 0xc04760fc lr = 0xc0466b04 (exception_exit) > sp = 0xdd3eec58 fp = 0xdd3eed10 > r4 = 0xc056b1cc r5 = 0xc2857da4 > r6 = 0xc2857d00 r7 = 0x3601a8c0 > r8 = 0x00000000 r9 = 0xc2857d88 > r10 = 0xc272fd00 > exception_exit() at exception_exit > pc = 0xc0466b04 lr = 0xc2819960 (0xc2819960) > sp = 0xdd3eecac fp = 0xdd3eed10 > r0 = 0x3601a8c0 r1 = 0xc272fb00 > r2 = 0xc04c14d9 r3 = 0x000005ef > r4 = 0xc056b1cc r5 = 0xc2857da4 > r6 = 0xc2857d00 r7 = 0x3601a8c0 > r8 = 0x00000000 r9 = 0xc2857d88 > r10 = 0xc272fd00 r12 = 0x00000000 > soreceive_generic() at soreceive_generic+0x4a8 > pc = 0xc02a9aec lr = 0xc02ab784 (soreceive+0x2c) > sp = 0xdd3eed18 fp = 0xdd3eed20 > r4 = 0xc2819960 r5 = 0x00000000 > r6 = 0xdd3eed98 r7 = 0x00000000 > r8 = 0x00000006 r9 = 0xc27c5c40 > r10 = 0x00000800 > soreceive() at soreceive+0x2c > pc = 0xc02ab784 lr = 0xc028da28 (soo_read+0x2c) > sp = 0xdd3eed28 fp = 0xdd3eed30 > soo_read() at soo_read+0x2c > pc = 0xc028da28 lr = 0xc0286aa4 (dofileread+0xa8) > sp = 0xdd3eed38 fp = 0xdd3eed58 > dofileread() at dofileread+0xa8 > pc = 0xc0286aa4 lr = 0xc0286764 (kern_readv+0x60) > sp = 0xdd3eed60 fp = 0xdd3eed88 > r4 = 0xffffffff r5 = 0x00000000 > r6 = 0x00000000 r7 = 0x00000006 > r8 = 0xdd3eed98 r9 = 0xc2819960 > r10 = 0x2081f0f0 > kern_readv() at kern_readv+0x60 > pc = 0xc0286764 lr = 0xc02866f4 (sys_read+0x4c) > sp = 0xdd3eed90 fp = 0xdd3eedb8 > r4 = 0xc2819960 r5 = 0x00000000 > r6 = 0xbfffe5a0 r7 = 0x00000000 > r8 = 0xdd3eee10 r9 = 0xc2872640 > sys_read() at sys_read+0x4c > pc = 0xc02866f4 lr = 0xc0476bc4 (swi_handler+0x284) > sp = 0xdd3eedc0 fp = 0xdd3eee58 > swi_handler() at swi_handler+0x284 > pc = 0xc0476bc4 lr = 0xc0466928 (swi_entry+0x2c) > sp = 0xdd3eee60 fp = 0xbfffedc0 > r4 = 0x000378f8 r5 = 0x0002d258 > r6 = 0xbfffe5a0 r7 = 0x00000003 > r8 = 0x00000000 r9 = 0x521d3a99 > swi_entry() at swi_entry+0x2c > pc = 0xc0466928 lr = 0xc0466928 (swi_entry+0x2c) > sp = 0xdd3eee60 fp = 0xbfffedc0 > Unable to unwind further > > vm_fault(0xc28989e0, 3601a000, 2, 0) -> 5 > Fatal kernel mode data abort: 'Translation Fault (S)' > trapframe: 0xdd3eec58 > FSR=00000805, FAR=3601a8c4, spsr=20000013 > r0 =3601a8c0, r1 =c272fb00, r2 =c04c14d9, r3 =000005ef > r4 =c056b1cc, r5 =c2857da4, r6 =c2857d00, r7 =3601a8c0 > r8 =00000000, r9 =c2857d88, r10=c272fd00, r11=dd3eed10 > r12=00000000, ssp=dd3eeca8, slr=c2819960, pc =c02a9aec > > [ thread pid 542 tid 100059 ] > Stopped at soreceive_generic+0x4a8: str r1, [r0, #0x004] > db> > > U-Boot 2013.01-rc1-g6709570-dirty (Aug 17 2013 - 23:35:05) > > DRAM: 480 MiB > WARNING: Caches not enabled > MMC: bcm2835_sdhci: 0 > Using default environment > > In: serial > Out: lcd > Err: lcd > mbox: Timeout waiting for response > bcm2835: Could not set USB power state > Net: Net Initialization Skipped > No ethernet found. > Hit any key to stop autoboot: 3  2  1  0 > reading uEnv.txt > 89 bytes read in 9553 ms (0 Bytes/s) > Importing environment from mmc ... > reading ubldr > 239540 bytes read in 54380 ms (3.9 KiB/s) > ## Starting application at 0x02000054 ... > Consoles: U-Boot console > Compatible API signature found @1db682a8 > Number of U-Boot devices: 1 > > FreeBSD/armv6 U-Boot loader, Revision 1.2 > (martin@pcbsd-7130, Wed Aug 28 01:32:51 CEST 2013) > DRAM: 480MB > > Device: disk > |/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|Loading /boot/defaults/loader.conf > /-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\/boot/kernel/kernel data=0x47b5e4+0x17e19c |/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|syms=[0x4+0x7fcb0/-\|/-\|/-\|/-\|+0x4+0x4d 613/-\|/-\|/-] > > Hit [Enter] to boot immediately, or any other key for command prompt. > Booting [/boot/kernel/kernel]... > \|/-\|/Using DTB provided by U-Boot. > Kernel entry at 0x100100... > Kernel args: (null) > 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-CURRENT #0 r254955M: Wed Aug 28 01:32:36 CEST 2013 > martin@pcbsd-7130:/usr/home/martin/Rasperry/crochet-freebsd/work/obj/arm.armv6/usr/home/martin/Rasperry/head/sys/RPI-B arm > FreeBSD clang version 3.3 (tags/RELEASE_33/final 183502) 20130610 > WARNING: WITNESS option enabled, expect reduced performance. > WARNING: DIAGNOSTIC option enabled, expect reduced performance. > CPU: 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 = 536870912 (512 MB) > avail memory = 482902016 (460 MB) > random device not loaded; using insecure entropy > 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 > bcm_dma0: mem 0x20007000-0x20007fff,0x20e05000-0x20e05fff irq 24,25,26,27,28,29,30,31,32,33,34,35,36 on simplebus0 > mbox0: mem 0x2000b880-0x2000b8bf irq 1 on simplebus0 > sdhci_bcm0: mem 0x20300000-0x203000ff irq 70 on simplebus0 > mmc0: on sdhci_bcm0 > uart0: mem 0x20201000-0x20201fff irq 65 on simplebus0 > uart0: console (115200,n,8,1) > dwcotg0: mem 0x20980000-0x2099ffff irq 17 on simplebus0 > usbus0 on dwcotg0 > simplebus1: on fdtbus0 > Timecounters tick every 10.000 msec > lock order reversal: > 1st 0xc06f3c0c entropy harvest mutex (entropy harvest mutex) @ /usr/home/martin/Rasperry/head/sys/dev/random/randomdev_soft.c:242 > 2nd 0xc25d7c20 uart_hwmtx (uart_hwmtx) @ /usr/home/martin/Rasperry/head/sys/dev/uart/uart_cpu.h:92 > KDB: stack backtrace: > db_trace_self() at db_trace_self > pc = 0xc04652cc lr = 0xc012e474 (db_trace_self_wrapper+0x30) > sp = 0xdc20c9c8 fp = 0xdc20cae0 > r10 = 0xc06f3c0c > db_trace_self_wrapper() at db_trace_self_wrapper+0x30 > pc = 0xc012e474 lr = 0xc0268974 (kdb_backtrace+0x38) > sp = 0xdc20cae8 fp = 0xdc20caf0 > r4 = 0xc05908a4 r5 = 0xc049fb59 > r6 = 0xc04bd04d r7 = 0xc049f1d4 > kdb_backtrace() at kdb_backtrace+0x38 > pc = 0xc0268974 lr = 0xc0282df8 (witness_checkorder+0xddc) > sp = 0xdc20caf8 fp = 0xdc20cb48 > r4 = 0xc049fa8a > witness_checkorder() at witness_checkorder+0xddc > pc = 0xc0282df8 lr = 0xc022050c (__mtx_lock_spin_flags+0xc4) > sp = 0xdc20cb50 fp = 0xdc20cb70 > r4 = 0x00000000 r5 = 0xc0580a84 > r6 = 0xc25d7c20 r7 = 0xc25d7c30 > r8 = 0x00000000 r9 = 0x0000005c > r10 = 0xc049fb56 > __mtx_lock_spin_flags() at __mtx_lock_spin_flags+0xc4 > pc = 0xc022050c lr = 0xc014e9a4 (uart_cnputc+0x44) > sp = 0xdc20cb78 fp = 0xdc20cb88 > r4 = 0x0000006c r5 = 0xc0580a84 > r6 = 0xc05908a0 r7 = 0xc0581700 > r8 = 0xc055d590 r9 = 0xc05816e0 > r10 = 0xdc20ccf0 > uart_cnputc() at uart_cnputc+0x44 > pc = 0xc014e9a4 lr = 0xc01eb6b0 (cnputc+0x80) > sp = 0xdc20cb90 fp = 0xdc20cba8 > r4 = 0x0000006c r5 = 0xc0551c30 > r6 = 0xc05908a0 > cnputc() at cnputc+0x80 > pc = 0xc01eb6b0 lr = 0xc026e6ec (putchar+0x194) > sp = 0xdc20cbb0 fp = 0xdc20cc18 > r4 = 0x00000005 r5 = 0xdc20ccf0 > r6 = 0x0000006c r7 = 0x00000000 > r8 = 0xc06f52b4 r9 = 0xc026e558 > putchar() at putchar+0x194 > pc = 0xc026e6ec lr = 0xc026d53c (kvprintf+0xb0) > sp = 0xdc20cc20 fp = 0xdc20ccd8 > r4 = 0xc04bc4c4 r5 = 0x00000000 > r6 = 0x00000000 r7 = 0x00000000 > r8 = 0xc06f52b4 r9 = 0xc026e558 > r10 = 0xdc20ccf0 > kvprintf() at kvprintf+0xb0 > pc = 0xc026d53c lr = 0xc026ec58 (printf+0x50) > sp = 0xdc20cce0 fp = 0xdc20cd10 > r4 = 0xc2446da8 r5 = 0xc2446a68 > r6 = 0x00000000 r7 = 0xc06c394c > r8 = 0xc06f52b4 r9 = 0x00000001 > r10 = 0xc06c395b > printf() at printf+0x50 > pc = 0xc026ec58 lr = 0xc0282b58 (witness_checkorder+0xb3c) > sp = 0xdc20cd28 fp = 0xdc20cd78 > witness_checkorder() at witness_checkorder+0xb3c > pc = 0xc0282b58 lr = 0xc022050c (__mtx_lock_spin_flags+0xc4) > sp = 0xdc20cd80 fp = 0xdc20cda0 > r4 = 0x00000000 r5 = 0x00000000 > r6 = 0xc059198c r7 = 0xc059199c > r8 = 0x00000000 r9 = 0x000000f0 > r10 = 0xc04ba67a > __mtx_lock_spin_flags() at __mtx_lock_spin_flags+0xc4 > pc = 0xc022050c lr = 0xc02751a4 (sleepq_lock+0x34) > sp = 0xdc20cda8 fp = 0xdc20cda8 > r4 = 0xc2582960 r5 = 0x00000000 > r6 = 0xc0580394 r7 = 0x00000000 > r8 = 0xc2584c80 r9 = 0x00000000 > r10 = 0xc0580390 > sleepq_lock() at sleepq_lock+0x34 > pc = 0xc02751a4 lr = 0xc023c4c0 (msleep_spin_sbt+0x80) > sp = 0xdc20cdb0 fp = 0xdc20cdf0 > msleep_spin_sbt() at msleep_spin_sbt+0x80 > pc = 0xc023c4c0 lr = 0xc0147458 (random_kthread+0x270) > sp = 0xdc20cdf8 fp = 0xdc20ce38 > r4 = 0xc06f3c1c r5 = 0x00000000 > r6 = 0xc049f1d1 r7 = 0x00000000 > r8 = 0x00000000 r9 = 0x00000000 > r10 = 0xc0580390 > random_kthread() at random_kthread+0x270 > pc = 0xc0147458 lr = 0xc02033f0 (fork_exit+0x88) > sp = 0xdc20ce40 fp = 0xdc20ce58 > r4 = 0xc2584c80 r5 = 0xc2582960 > r6 = 0xc01471e8 r7 = 0x00000000 > r8 = 0xdc20ce60 r9 = 0x00000000 > r10 = 0x00000000 > fork_exit() at fork_exit+0x88 > pc = 0xc02033f0 lr = 0xc0475cec (fork_trampoline+0x14) > sp = 0xdc20ce60 fp = 0x00000000 > r4 = 0xc01471e8 r5 = 0x00000000 > r6 = 0xc0c0c0c0 r7 = 0xc0c0c0c0 > r8 = 0x00000000 > fork_trampoline() at fork_trampoline+0x14 > pc = 0xc0475cec lr = 0xc0475cec (fork_trampoline+0x14) > sp = 0xdc20ce60 fp = 0x00000000 > Unable to unwind further > lock order reversal: > 1st 0xc06f3c0c entropy harvest mutex (entropy harvest mutex) @ /usr/home/martin/Rasperry/head/sys/dev/random/randomdev_soft.c:242 > 2nd 0xc059198c sleepq chain (sleepq chain) @ /usr/home/martin/Rasperry/head/sys/kern/subr_sleepqueue.c:240 > KDB: stack backtrace: > db_trace_self() at db_trace_self > pc = 0xc04652cc lr = 0xc012e474 (db_trace_self_wrapper+0x30) > sp = 0xdc20cbf8 fp = 0xdc20cd10 > r10 = 0xc06f3c0c > db_trace_self_wrapper() at db_trace_self_wrapper+0x30 > pc = 0xc012e474 lr = 0xc0268974 (kdb_backtrace+0x38) > sp = 0xdc20cd18 fp = 0xdc20cd20 > r4 = 0xc05908a4 r5 = 0xc04ba67d > r6 = 0xc04bd04d r7 = 0xc049f1d4 > kdb_backtrace() at kdb_backtrace+0x38 > pc = 0xc0268974 lr = 0xc0282df8 (witness_checkorder+0xddc) > sp = 0xdc20cd28 fp = 0xdc20cd78 > r4 = 0xc04ba662 > witness_checkorder() at witness_checkorder+0xddc > pc = 0xc0282df8 lr = 0xc022050c (__mtx_lock_spin_flags+0xc4) > sp = 0xdc20cd80 fp = 0xdc20cda0 > r4 = 0x00000000 r5 = 0x00000000 > r6 = 0xc059198c r7 = 0xc059199c > r8 = 0x00000000 r9 = 0x000000f0 > r10 = 0xc04ba67a > __mtx_lock_spin_flags() at __mtx_lock_spin_flags+0xc4 > pc = 0xc022050c lr = 0xc02751a4 (sleepq_lock+0x34) > sp = 0xdc20cda8 fp = 0xdc20cda8 > r4 = 0xc2582960 r5 = 0x00000000 > r6 = 0xc0580394 r7 = 0x00000000 > r8 = 0xc2584c80 r9 = 0x00000000 > r10 = 0xc0580390 > sleepq_lock() at sleepq_lock+0x34 > pc = 0xc02751a4 lr = 0xc023c4c0 (msleep_spin_sbt+0x80) > sp = 0xdc20cdb0 fp = 0xdc20cdf0 > msleep_spin_sbt() at msleep_spin_sbt+0x80 > pc = 0xc023c4c0 lr = 0xc0147458 (random_kthread+0x270) > sp = 0xdc20cdf8 fp = 0xdc20ce38 > r4 = 0xc06f3c1c r5 = 0x00000000 > r6 = 0xc049f1d1 r7 = 0x00000000 > r8 = 0x00000000 r9 = 0x00000000 > r10 = 0xc0580390 > random_kthread() at random_kthread+0x270 > pc = 0xc0147458 lr = 0xc02033f0 (fork_exit+0x88) > sp = 0xdc20ce40 fp = 0xdc20ce58 > r4 = 0xc2584c80 r5 = 0xc2582960 > r6 = 0xc01471e8 r7 = 0x00000000 > r8 = 0xdc20ce60 r9 = 0x00000000 > r10 = 0x00000000 > fork_exit() at fork_exit+0x88 > pc = 0xc02033f0 lr = 0xc0475cec (fork_trampoline+0x14) > sp = 0xdc20ce60 fp = 0x00000000 > r4 = 0xc01471e8 r5 = 0x00000000 > r6 = 0xc0c0c0c0 r7 = 0xc0c0c0c0 > r8 = 0x00000000 > fork_trampoline() at fork_trampoline+0x14 > pc = 0xc0475cec lr = 0xc0475cec (fork_trampoline+0x14) > sp = 0xdc20ce60 fp = 0x00000000 > Unable to unwind further > usbus0: 480Mbps High Speed USB v2.0 > ugen0.1: at usbus0 > uhub0: on usbus0 > mmcsd0: 8GB at mmc0 25.0MHz/4bit/65535-block > WARNING: WITNESS option enabled, expect reduced performance. > WARNING: DIAGNOSTIC option enabled, expect reduced performance. > Root mount waiting for: usbus0 > uhub0: 1 port with 1 removable, self powered > ugen0.2: at usbus0 > uhub1: on usbus0 > uhub1: MTT enabled > Root mount waiting for: usbus0 > uhub1: 3 ports with 2 removable, self powered > Root mount waiting for: usbus0 > ugen0.3: at usbus0 > smsc0: on usbus0 > Trying to mount root from ufs:/dev/mmcsd0s2a [rw,noatime]... > WARNING: / was not properly dismounted > smsc0: chip 0xec00, rev. 0002 > warning: no time-of-day clock registered, system time will not be set accurately > miibus0: on smsc0 > ukphy0: PHY 1 on miibus0 > ukphy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto > ue0: on smsc0 > ue0: Ethernet address: b8:27:eb:1d:b7:5a > Enlarging root partition > mmcsd0s2 resized > mmcsd0s2a resized > super-block backups (for fsck -b #) at: > > Setting hostuuid: 0cff015d-0f73-11e3-b289-b827eb1db75a. > Setting hostid: 0xe90281aa. > No suitable dump device was found. > Entropy harvesting: interrupts ethernet point_to_point > > U-Boot 2013.01-rc1-g6709570-dirty (Aug 17 2013 - 23:35:05) > > DRAM: 480 MiB > WARNING: Caches not enabled > MMC: bcm2835_sdhci: 0 > Using default environment > > In: serial > Out: lcd > Err: lcd > mbox: Timeout waiting for response > bcm2835: Could not set USB power state > Net: Net Initialization Skipped > No ethernet found. > Hit any key to stop autoboot: 3  2  1  0 > reading uEnv.txt > 89 bytes read in 9552 ms (0 Bytes/s) > Importing environment from mmc ... > reading ubldr > 239540 bytes read in 54417 ms (3.9 KiB/s) > ## Starting application at 0x02000054 ... > Consoles: U-Boot console > Compatible API signature found @1db682a8 > Number of U-Boot devices: 1 > > FreeBSD/armv6 U-Boot loader, Revision 1.2 > (martin@pcbsd-7130, Wed Aug 28 01:32:51 CEST 2013) > DRAM: 480MB > > Device: disk > |/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|Loading /boot/defaults/loader.conf > /-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\/boot/kernel/kernel data=0x47b5e4+0x17e19c |/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|syms=[0x4+0x7fcb0/-\|/-\|/-\|/-\|+0x4+0x4d 613/-\|/-\|/-] > > Hit [Enter] to boot immediately, or any other key for command prompt. > Booting [/boot/kernel/kernel]... > \|/-\|/Using DTB provided by U-Boot. > Kernel entry at 0x100100... > Kernel args: (null) > 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-CURRENT #0 r254955M: Wed Aug 28 01:32:36 CEST 2013 > martin@pcbsd-7130:/usr/home/martin/Rasperry/crochet-freebsd/work/obj/arm.armv6/usr/home/martin/Rasperry/head/sys/RPI-B arm > FreeBSD clang version 3.3 (tags/RELEASE_33/final 183502) 20130610 > WARNING: WITNESS option enabled, expect reduced performance. > WARNING: DIAGNOSTIC option enabled, expect reduced performance. > CPU: 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 = 536870912 (512 MB) > avail memory = 482902016 (460 MB) > random device not loaded; using insecure entropy > 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 > bcm_dma0: mem 0x20007000-0x20007fff,0x20e05000-0x20e05fff irq 24,25,26,27,28,29,30,31,32,33,34,35,36 on simplebus0 > mbox0: mem 0x2000b880-0x2000b8bf irq 1 on simplebus0 > sdhci_bcm0: mem 0x20300000-0x203000ff irq 70 on simplebus0 > mmc0: on sdhci_bcm0 > uart0: mem 0x20201000-0x20201fff irq 65 on simplebus0 > uart0: console (115200,n,8,1) > dwcotg0: mem 0x20980000-0x2099ffff irq 17 on simplebus0 > usbus0 on dwcotg0 > simplebus1: on fdtbus0 > Timecounters tick every 10.000 msec > lock order reversal: > 1st 0xc06f3c0c entropy harvest mutex (entropy harvest mutex) @ /usr/home/martin/Rasperry/head/sys/dev/random/randomdev_soft.c:242 > 2nd 0xc25d7c20 uart_hwmtx (uart_hwmtx) @ /usr/home/martin/Rasperry/head/sys/dev/uart/uart_cpu.h:92 > KDB: stack backtrace: > db_trace_self() at db_trace_self > pc = 0xc04652cc lr = 0xc012e474 (db_trace_self_wrapper+0x30) > sp = 0xdc20c9c8 fp = 0xdc20cae0 > r10 = 0xc06f3c0c > db_trace_self_wrapper() at db_trace_self_wrapper+0x30 > pc = 0xc012e474 lr = 0xc0268974 (kdb_backtrace+0x38) > sp = 0xdc20cae8 fp = 0xdc20caf0 > r4 = 0xc05908a4 r5 = 0xc049fb59 > r6 = 0xc04bd04d r7 = 0xc049f1d4 > kdb_backtrace() at kdb_backtrace+0x38 > pc = 0xc0268974 lr = 0xc0282df8 (witness_checkorder+0xddc) > sp = 0xdc20caf8 fp = 0xdc20cb48 > r4 = 0xc049fa8a > witness_checkorder() at witness_checkorder+0xddc > pc = 0xc0282df8 lr = 0xc022050c (__mtx_lock_spin_flags+0xc4) > sp = 0xdc20cb50 fp = 0xdc20cb70 > r4 = 0x00000000 r5 = 0xc0580a84 > r6 = 0xc25d7c20 r7 = 0xc25d7c30 > r8 = 0x00000000 r9 = 0x0000005c > r10 = 0xc049fb56 > __mtx_lock_spin_flags() at __mtx_lock_spin_flags+0xc4 > pc = 0xc022050c lr = 0xc014e9a4 (uart_cnputc+0x44) > sp = 0xdc20cb78 fp = 0xdc20cb88 > r4 = 0x0000006c r5 = 0xc0580a84 > r6 = 0xc05908a0 r7 = 0xc0581700 > r8 = 0xc055d590 r9 = 0xc05816e0 > r10 = 0xdc20ccf0 > uart_cnputc() at uart_cnputc+0x44 > pc = 0xc014e9a4 lr = 0xc01eb6b0 (cnputc+0x80) > sp = 0xdc20cb90 fp = 0xdc20cba8 > r4 = 0x0000006c r5 = 0xc0551c30 > r6 = 0xc05908a0 > cnputc() at cnputc+0x80 > pc = 0xc01eb6b0 lr = 0xc026e6ec (putchar+0x194) > sp = 0xdc20cbb0 fp = 0xdc20cc18 > r4 = 0x00000005 r5 = 0xdc20ccf0 > r6 = 0x0000006c r7 = 0x00000000 > r8 = 0xc06f52b4 r9 = 0xc026e558 > putchar() at putchar+0x194 > pc = 0xc026e6ec lr = 0xc026d53c (kvprintf+0xb0) > sp = 0xdc20cc20 fp = 0xdc20ccd8 > r4 = 0xc04bc4c4 r5 = 0x00000000 > r6 = 0x00000000 r7 = 0x00000000 > r8 = 0xc06f52b4 r9 = 0xc026e558 > r10 = 0xdc20ccf0 > kvprintf() at kvprintf+0xb0 > pc = 0xc026d53c lr = 0xc026ec58 (printf+0x50) > sp = 0xdc20cce0 fp = 0xdc20cd10 > r4 = 0xc2446da8 r5 = 0xc2446a68 > r6 = 0x00000000 r7 = 0xc06c394c > r8 = 0xc06f52b4 r9 = 0x00000001 > r10 = 0xc06c395b > printf() at printf+0x50 > pc = 0xc026ec58 lr = 0xc0282b58 (witness_checkorder+0xb3c) > sp = 0xdc20cd28 fp = 0xdc20cd78 > witness_checkorder() at witness_checkorder+0xb3c > pc = 0xc0282b58 lr = 0xc022050c (__mtx_lock_spin_flags+0xc4) > sp = 0xdc20cd80 fp = 0xdc20cda0 > r4 = 0x00000000 r5 = 0x00000000 > r6 = 0xc059198c r7 = 0xc059199c > r8 = 0x00000000 r9 = 0x000000f0 > r10 = 0xc04ba67a > __mtx_lock_spin_flags() at __mtx_lock_spin_flags+0xc4 > pc = 0xc022050c lr = 0xc02751a4 (sleepq_lock+0x34) > sp = 0xdc20cda8 fp = 0xdc20cda8 > r4 = 0xc2582960 r5 = 0x00000000 > r6 = 0xc0580394 r7 = 0x00000000 > r8 = 0xc2584c80 r9 = 0x00000000 > r10 = 0xc0580390 > sleepq_lock() at sleepq_lock+0x34 > pc = 0xc02751a4 lr = 0xc023c4c0 (msleep_spin_sbt+0x80) > sp = 0xdc20cdb0 fp = 0xdc20cdf0 > msleep_spin_sbt() at msleep_spin_sbt+0x80 > pc = 0xc023c4c0 lr = 0xc0147458 (random_kthread+0x270) > sp = 0xdc20cdf8 fp = 0xdc20ce38 > r4 = 0xc06f3c1c r5 = 0x00000000 > r6 = 0xc049f1d1 r7 = 0x00000000 > r8 = 0x00000000 r9 = 0x00000000 > r10 = 0xc0580390 > random_kthread() at random_kthread+0x270 > pc = 0xc0147458 lr = 0xc02033f0 (fork_exit+0x88) > sp = 0xdc20ce40 fp = 0xdc20ce58 > r4 = 0xc2584c80 r5 = 0xc2582960 > r6 = 0xc01471e8 r7 = 0x00000000 > r8 = 0xdc20ce60 r9 = 0x00000000 > r10 = 0x00000000 > fork_exit() at fork_exit+0x88 > pc = 0xc02033f0 lr = 0xc0475cec (fork_trampoline+0x14) > sp = 0xdc20ce60 fp = 0x00000000 > r4 = 0xc01471e8 r5 = 0x00000000 > r6 = 0xc0c0c0c0 r7 = 0xc0c0c0c0 > r8 = 0x00000000 > fork_trampoline() at fork_trampoline+0x14 > pc = 0xc0475cec lr = 0xc0475cec (fork_trampoline+0x14) > sp = 0xdc20ce60 fp = 0x00000000 > Unable to unwind further > lock order reversal: > 1st 0xc06f3c0c entropy harvest mutex (entropy harvest mutex) @ /usr/home/martin/Rasperry/head/sys/dev/random/randomdev_soft.c:242 > 2nd 0xc059198c sleepq chain (sleepq chain) @ /usr/home/martin/Rasperry/head/sys/kern/subr_sleepqueue.c:240 > KDB: stack backtrace: > db_trace_self() at db_trace_self > pc = 0xc04652cc lr = 0xc012e474 (db_trace_self_wrapper+0x30) > sp = 0xdc20cbf8 fp = 0xdc20cd10 > r10 = 0xc06f3c0c > db_trace_self_wrapper() at db_trace_self_wrapper+0x30 > pc = 0xc012e474 lr = 0xc0268974 (kdb_backtrace+0x38) > sp = 0xdc20cd18 fp = 0xdc20cd20 > r4 = 0xc05908a4 r5 = 0xc04ba67d > r6 = 0xc04bd04d r7 = 0xc049f1d4 > kdb_backtrace() at kdb_backtrace+0x38 > pc = 0xc0268974 lr = 0xc0282df8 (witness_checkorder+0xddc) > sp = 0xdc20cd28 fp = 0xdc20cd78 > r4 = 0xc04ba662 > witness_checkorder() at witness_checkorder+0xddc > pc = 0xc0282df8 lr = 0xc022050c (__mtx_lock_spin_flags+0xc4) > sp = 0xdc20cd80 fp = 0xdc20cda0 > r4 = 0x00000000 r5 = 0x00000000 > r6 = 0xc059198c r7 = 0xc059199c > r8 = 0x00000000 r9 = 0x000000f0 > r10 = 0xc04ba67a > __mtx_lock_spin_flags() at __mtx_lock_spin_flags+0xc4 > pc = 0xc022050c lr = 0xc02751a4 (sleepq_lock+0x34) > sp = 0xdc20cda8 fp = 0xdc20cda8 > r4 = 0xc2582960 r5 = 0x00000000 > r6 = 0xc0580394 r7 = 0x00000000 > r8 = 0xc2584c80 r9 = 0x00000000 > r10 = 0xc0580390 > sleepq_lock() at sleepq_lock+0x34 > pc = 0xc02751a4 lr = 0xc023c4c0 (msleep_spin_sbt+0x80) > sp = 0xdc20cdb0 fp = 0xdc20cdf0 > msleep_spin_sbt() at msleep_spin_sbt+0x80 > pc = 0xc023c4c0 lr = 0xc0147458 (random_kthread+0x270) > sp = 0xdc20cdf8 fp = 0xdc20ce38 > r4 = 0xc06f3c1c r5 = 0x00000000 > r6 = 0xc049f1d1 r7 = 0x00000000 > r8 = 0x00000000 r9 = 0x00000000 > r10 = 0xc0580390 > random_kthread() at random_kthread+0x270 > pc = 0xc0147458 lr = 0xc02033f0 (fork_exit+0x88) > sp = 0xdc20ce40 fp = 0xdc20ce58 > r4 = 0xc2584c80 r5 = 0xc2582960 > r6 = 0xc01471e8 r7 = 0x00000000 > r8 = 0xdc20ce60 r9 = 0x00000000 > r10 = 0x00000000 > fork_exit() at fork_exit+0x88 > pc = 0xc02033f0 lr = 0xc0475cec (fork_trampoline+0x14) > sp = 0xdc20ce60 fp = 0x00000000 > r4 = 0xc01471e8 r5 = 0x00000000 > r6 = 0xc0c0c0c0 r7 = 0xc0c0c0c0 > r8 = 0x00000000 > fork_trampoline() at fork_trampoline+0x14 > pc = 0xc0475cec lr = 0xc0475cec (fork_trampoline+0x14) > sp = 0xdc20ce60 fp = 0x00000000 > Unable to unwind further > usbus0: 480Mbps High Speed USB v2.0 > ugen0.1: at usbus0 > uhub0: on usbus0 > mmcsd0: 8GB at mmc0 25.0MHz/4bit/65535-block > WARNING: WITNESS option enabled, expect reduced performance. > WARNING: DIAGNOSTIC option enabled, expect reduced performance. > Root mount waiting for: usbus0 > uhub0: 1 port with 1 removable, self powered > Root mount waiting for: usbus0 > ugen0.2: at usbus0 > uhub1: on usbus0 > uhub1: MTT enabled > uhub1: 3 ports with 2 removable, self powered > Root mount waiting for: usbus0 > ugen0.3: at usbus0 > smsc0: on usbus0 > Trying to mount root from ufs:/dev/mmcsd0s2a [rw,noatime]... > WARNING: / was not properly dismounted > smsc0: chip 0xec00, rev. 0002 > warning: no time-of-day clock registered, system time will not be set accurately > miibus0: on smsc0 > ukphy0: PHY 1 on miibus0 > ukphy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto > ue0: on smsc0 > ue0: Ethernet address: b8:27:eb:1d:b7:5a > Enlarging root partition > mmcsd0s2 resized > mmcsd0s2a resized > super-block backups (for fsck -b #) at: > > Setting hostuuid: 27d85b91-0f73-11e3-b289-b827eb1db75a. > Setting hostid: 0xaa3c183b. > No suitable dump device was found. > Entropy harvesting: interrupts ethernet point_to_point kickstart. > Starting file system checks: > ** SU+J Recovering /dev/mmcsd0s2a > ** Reading 4194304 byte journal from inode 4. > ** Building recovery table. > ** Resolving unreferenced inode list. > ** Processing journal entries. > ** 28 journal records in 4096 bytes for 21.88% utilization > ** Freed 0 inodes (0 dirs) 0 blocks, and 0 frags. > > ***** FILE SYSTEM MARKED CLEAN ***** > Mounting local file systems:. > Writing entropy file:. > Setting hostname: raspberry-pi. > smsc0: chip 0xec00, rev. 0002 > ue0: link state changed to DOWN > ue0: link state changed to UP > Starting Network: lo0 ue0. > lo0: flags=8049 metric 0 mtu 16384 > options=600003 > inet6 ::1 prefixlen 128 > inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1 > inet 127.0.0.1 netmask 0xff000000 > nd6 options=21 > ue0: flags=8843 metric 0 mtu 1500 > options=80001 > ether b8:27:eb:1d:b7:5a > media: Ethernet autoselect (100baseTX ) > status: active > nd6 options=29 > Starting devd. > Starting dhclient. > DHCPDISCOVER on ue0 to 255.255.255.255 port 67 interval 7 > DHCPOFFER from 192.168.1.250 > DHCPREQUEST on ue0 to 255.255.255.255 port 67 > DHCPACK from 192.168.1.250 > bound to 192.168.1.54 -- renewal in 300 seconds. > lock order reversal: (sleepable after non-sleepable) > 1st 0xc2857d78 so_rcv (so_rcv) @ /usr/home/martin/Rasperry/head/sys/kern/uipc_socket.c:1594 > 2nd 0xc2899a30 vm map (user) (vm map (user)) @ /usr/home/martin/Rasperry/head/sys/vm/vm_map.c:3816 > KDB: stack backtrace: > db_trace_self() at db_trace_self > pc = 0xc04652cc lr = 0xc012e474 (db_trace_self_wrapper+0x30) > sp = 0xdd3ee818 fp = 0xdd3ee930 > r10 = 0xc2857d78 > db_trace_self_wrapper() at db_trace_self_wrapper+0x30 > pc = 0xc012e474 lr = 0xc0268974 (kdb_backtrace+0x38) > sp = 0xdd3ee938 fp = 0xdd3ee940 > r4 = 0xc05908a4 r5 = 0xc04dce80 > r6 = 0xc04bd04d r7 = 0xc04c14dc > kdb_backtrace() at kdb_backtrace+0x38 > pc = 0xc0268974 lr = 0xc0282df8 (witness_checkorder+0xddc) > sp = 0xdd3ee948 fp = 0xdd3ee998 > r4 = 0xc04bd221 > witness_checkorder() at witness_checkorder+0xddc > pc = 0xc0282df8 lr = 0xc023aaf0 (_sx_slock+0x84) > sp = 0xdd3ee9a0 fp = 0xdd3ee9c8 > r4 = 0x00000ee8 r5 = 0xc04dce7d > r6 = 0xc2899a30 r7 = 0xc2899a40 > r8 = 0x00000000 r9 = 0x00000000 > r10 = 0xdd3eeb2c > _sx_slock() at _sx_slock+0x84 > pc = 0xc023aaf0 lr = 0xc044579c (vm_map_lookup+0x74) > sp = 0xdd3ee9d0 fp = 0xdd3eea08 > r4 = 0xc28999e0 r5 = 0xc04dce7d > r6 = 0x3601a000 r7 = 0x3601a000 > r8 = 0x00000002 > vm_map_lookup() at vm_map_lookup+0x74 > pc = 0xc044579c lr = 0xc0439a18 (vm_fault_hold+0xe4) > sp = 0xdd3eea10 fp = 0xdd3eeb80 > r4 = 0xc28999e0 r5 = 0x00000002 > r6 = 0xc2819960 r7 = 0x3601a000 > r8 = 0xdd3eeb10 r9 = 0x00000000 > r10 = 0xc06f7af0 > vm_fault_hold() at vm_fault_hold+0xe4 > pc = 0xc0439a18 lr = 0xc04398ec (vm_fault+0x88) > sp = 0xdd3eeb88 fp = 0xdd3eeba8 > r4 = 0xc28999e0 r5 = 0x00000002 > r6 = 0xc2819960 r7 = 0x3601a000 > r8 = 0x00000000 r9 = 0x00000002 > r10 = 0xc06f7af0 > vm_fault() at vm_fault+0x88 > pc = 0xc04398ec lr = 0xc04760fc (data_abort_handler+0x2a8) > sp = 0xdd3eebb0 fp = 0xdd3eec50 > r4 = 0xc2872640 r5 = 0xc2819960 > r6 = 0xc04e30cc r7 = 0xc28726e8 > r8 = 0xdd3eec58 r9 = 0xdd3eeeb0 > r10 = 0xc28999e0 > data_abort_handler() at data_abort_handler+0x2a8 > pc = 0xc04760fc lr = 0xc0466b04 (exception_exit) > sp = 0xdd3eec58 fp = 0xdd3eed10 > r4 = 0xc056b1cc r5 = 0xc2857da4 > r6 = 0xc2857d00 r7 = 0x3601a8c0 > r8 = 0x00000000 r9 = 0xc2857d88 > r10 = 0xc272fd00 > exception_exit() at exception_exit > pc = 0xc0466b04 lr = 0xc2819960 (0xc2819960) > sp = 0xdd3eecac fp = 0xdd3eed10 > r0 = 0x3601a8c0 r1 = 0xc272fb00 > r2 = 0xc04c14d9 r3 = 0x000005ef > r4 = 0xc056b1cc r5 = 0xc2857da4 > r6 = 0xc2857d00 r7 = 0x3601a8c0 > r8 = 0x00000000 r9 = 0xc2857d88 > r10 = 0xc272fd00 r12 = 0x00000000 > soreceive_generic() at soreceive_generic+0x4a8 > pc = 0xc02a9aec lr = 0xc02ab784 (soreceive+0x2c) > sp = 0xdd3eed18 fp = 0xdd3eed20 > r4 = 0xc2819960 r5 = 0x00000000 > r6 = 0xdd3eed98 r7 = 0x00000000 > r8 = 0x00000006 r9 = 0xc27c5c40 > r10 = 0x00000800 > soreceive() at soreceive+0x2c > pc = 0xc02ab784 lr = 0xc028da28 (soo_read+0x2c) > sp = 0xdd3eed28 fp = 0xdd3eed30 > soo_read() at soo_read+0x2c > pc = 0xc028da28 lr = 0xc0286aa4 (dofileread+0xa8) > sp = 0xdd3eed38 fp = 0xdd3eed58 > dofileread() at dofileread+0xa8 > pc = 0xc0286aa4 lr = 0xc0286764 (kern_readv+0x60) > sp = 0xdd3eed60 fp = 0xdd3eed88 > r4 = 0xffffffff r5 = 0x00000000 > r6 = 0x00000000 r7 = 0x00000006 > r8 = 0xdd3eed98 r9 = 0xc2819960 > r10 = 0x2081f0f0 > kern_readv() at kern_readv+0x60 > pc = 0xc0286764 lr = 0xc02866f4 (sys_read+0x4c) > sp = 0xdd3eed90 fp = 0xdd3eedb8 > r4 = 0xc2819960 r5 = 0x00000000 > r6 = 0xbfffe5a0 r7 = 0x00000000 > r8 = 0xdd3eee10 r9 = 0xc2872640 > sys_read() at sys_read+0x4c > pc = 0xc02866f4 lr = 0xc0476bc4 (swi_handler+0x284) > sp = 0xdd3eedc0 fp = 0xdd3eee58 > swi_handler() at swi_handler+0x284 > pc = 0xc0476bc4 lr = 0xc0466928 (swi_entry+0x2c) > sp = 0xdd3eee60 fp = 0xbfffedc0 > r4 = 0x000378f8 r5 = 0x0002d258 > r6 = 0xbfffe5a0 r7 = 0x00000003 > r8 = 0x00000000 r9 = 0x521d3af3 > swi_entry() at swi_entry+0x2c > pc = 0xc0466928 lr = 0xc0466928 (swi_entry+0x2c) > sp = 0xdd3eee60 fp = 0xbfffedc0 > Unable to unwind further > > vm_fault(0xc28999e0, 3601a000, 2, 0) -> 5 > Fatal kernel mode data abort: 'Translation Fault (S)' > trapframe: 0xdd3eec58 > FSR=00000805, FAR=3601a8c4, spsr=20000013 > r0 =3601a8c0, r1 =c272fb00, r2 =c04c14d9, r3 =000005ef > r4 =c056b1cc, r5 =c2857da4, r6 =c2857d00, r7 =3601a8c0 > r8 =00000000, r9 =c2857d88, r10=c272fd00, r11=dd3eed10 > r12=00000000, ssp=dd3eeca8, slr=c2819960, pc =c02a9aec > > [ thread pid 542 tid 100059 ] > Stopped at soreceive_generic+0x4a8: str r1, [r0, #0x004] > db> > > >Release-Note: > >Audit-Trail: > >Unformatted: This problem was caused by recent changes to the layout of struct mbuf and the structures embedded within it. Fixed in r254973. From owner-freebsd-arm@FreeBSD.ORG Wed Aug 28 12:30:01 2013 Return-Path: Delivered-To: freebsd-arm@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 4A347296 for ; Wed, 28 Aug 2013 12:30:01 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 372E923A0 for ; Wed, 28 Aug 2013 12:30:01 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r7SCU1aU093957 for ; Wed, 28 Aug 2013 12:30:01 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r7SCU0k5093956; Wed, 28 Aug 2013 12:30:00 GMT (envelope-from gnats) Date: Wed, 28 Aug 2013 12:30:00 GMT Message-Id: <201308281230.r7SCU0k5093956@freefall.freebsd.org> To: freebsd-arm@FreeBSD.org Cc: From: Ian Lepore Subject: Re: arm/181601: Sporadic failure of root mount on ARM/Raspberry X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Ian Lepore List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Aug 2013 12:30:01 -0000 The following reply was made to PR arm/181601; it has been noted by GNATS. From: Ian Lepore To: Martin Laabs Cc: freebsd-gnats-submit@FreeBSD.org Subject: Re: arm/181601: Sporadic failure of root mount on ARM/Raspberry Date: Wed, 28 Aug 2013 06:23:02 -0600 On Wed, 2013-08-28 at 05:35 +0000, Martin Laabs wrote: > >Number: 181601 > >Category: arm > >Synopsis: Sporadic failure of root mount on ARM/Raspberry > >Confidential: no > >Severity: non-critical > >Priority: low > >Responsible: freebsd-arm > >State: open > >Quarter: > >Keywords: > >Date-Required: > >Class: sw-bug > >Submitter-Id: current-users > >Arrival-Date: Wed Aug 28 05:40:00 UTC 2013 > >Closed-Date: > >Last-Modified: > >Originator: Martin Laabs > >Release: FreeBSD 10.0-CURRENT #0 r254955M > >Organization: > - > >Environment: > not available > >Description: > Sporadicly the raspberry pi failes to mount its root mmc card. After power off and power on again works most of the time. However there seem to be also configurations that fail permanently. Unfortunately I have no image of a sd card that fails on every boot. The full boot log output is attached to this bug report. > > > Trying to mount root from ufs:/dev/mmcsd0s2a [rw,noatime]... > mountroot: waiting for device /dev/mmcsd0s2a ... > smsc0: chip 0xec00, rev. 0002 > miibus0: on smsc0 > ukphy0: PHY 1 on miibus0 > ukphy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto > ue0: on smsc0 > ue0: Ethernet address: b8:27:eb:1d:b7:5a > Mounting from ufs:/dev/mmcsd0s2a failed with error 19. > > Loader variables: > vfs.root.mountfrom=ufs:/dev/mmcsd0s2a > vfs.root.mountfrom.options=rw,noatime > > Manual root filesystem specification: > : [options] > Mount using filesystem > and with the specified (optional) option list. > > eg. ufs:/dev/da0s1a > zfs:tank > cd9660:/dev/acd0 ro > (which is equivalent to: mount -t cd9660 -o ro /dev/acd0 /) > > ? List valid disk boot devices > . Yield 1 second (for background tasks) > Abort manual input > > mountroot> > > >How-To-Repeat: > Boot the Raspberry Pi several times and look if > >Fix: > > > Patch attached with submission follows: > > > > U-Boot 2013.01-rc1-g6709570-dirty (Aug 17 2013 - 23:35:05) > > DRAM: 480 MiB > WARNING: Caches not enabled > MMC: bcm2835_sdhci: 0 > Using default environment > > In: serial > Out: lcd > Err: lcd > mbox: Timeout waiting for response > bcm2835: Could not set USB power state > Net: Net Initialization Skipped > No ethernet found. > Hit any key to stop autoboot: 3  2  1  0 > reading uEnv.txt > 89 bytes read in 9541 ms (0 Bytes/s) > Importing environment from mmc ... > reading ubldr > 239540 bytes read in 54396 ms (3.9 KiB/s) > ## Starting application at 0x02000054 ... > Consoles: U-Boot console > Compatible API signature found @1db682a8 > Number of U-Boot devices: 1 > > FreeBSD/armv6 U-Boot loader, Revision 1.2 > (martin@pcbsd-7130, Wed Aug 28 01:32:51 CEST 2013) > DRAM: 480MB > > Device: disk > |/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|Loading /boot/defaults/loader.conf > /-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\/boot/kernel/kernel data=0x47b5e4+0x17e19c |/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|syms=[0x4+0x7fcb0/-\|/-\|/-\|/-\|+0x4+0x4d 613/-\|/-\|/-] > > Hit [Enter] to boot immediately, or any other key for command prompt. > Booting [/boot/kernel/kernel]... > \|/-\|/Using DTB provided by U-Boot. > Kernel entry at 0x100100... > Kernel args: (null) > 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-CURRENT #0 r254955M: Wed Aug 28 01:32:36 CEST 2013 > martin@pcbsd-7130:/usr/home/martin/Rasperry/crochet-freebsd/work/obj/arm.armv6/usr/home/martin/Rasperry/head/sys/RPI-B arm > FreeBSD clang version 3.3 (tags/RELEASE_33/final 183502) 20130610 > WARNING: WITNESS option enabled, expect reduced performance. > WARNING: DIAGNOSTIC option enabled, expect reduced performance. > CPU: 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 = 536870912 (512 MB) > avail memory = 482902016 (460 MB) > random device not loaded; using insecure entropy > 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 > bcm_dma0: mem 0x20007000-0x20007fff,0x20e05000-0x20e05fff irq 24,25,26,27,28,29,30,31,32,33,34,35,36 on simplebus0 > mbox0: mem 0x2000b880-0x2000b8bf irq 1 on simplebus0 > sdhci_bcm0: mem 0x20300000-0x203000ff irq 70 on simplebus0 > mmc0: on sdhci_bcm0 > uart0: mem 0x20201000-0x20201fff irq 65 on simplebus0 > uart0: console (115200,n,8,1) > dwcotg0: mem 0x20980000-0x2099ffff irq 17 on simplebus0 > usbus0 on dwcotg0 > simplebus1: on fdtbus0 > Timecounters tick every 10.000 msec > lock order reversal: > 1st 0xc06f3c0c entropy harvest mutex (entropy harvest mutex) @ /usr/home/martin/Rasperry/head/sys/dev/random/randomdev_soft.c:242 > 2nd 0xc25d7c20 uart_hwmtx (uart_hwmtx) @ /usr/home/martin/Rasperry/head/sys/dev/uart/uart_cpu.h:92 > KDB: stack backtrace: > db_trace_self() at db_trace_self > pc = 0xc04652cc lr = 0xc012e474 (db_trace_self_wrapper+0x30) > sp = 0xdc20c9c8 fp = 0xdc20cae0 > r10 = 0xc06f3c0c > db_trace_self_wrapper() at db_trace_self_wrapper+0x30 > pc = 0xc012e474 lr = 0xc0268974 (kdb_backtrace+0x38) > sp = 0xdc20cae8 fp = 0xdc20caf0 > r4 = 0xc05908a4 r5 = 0xc049fb59 > r6 = 0xc04bd04d r7 = 0xc049f1d4 > kdb_backtrace() at kdb_backtrace+0x38 > pc = 0xc0268974 lr = 0xc0282df8 (witness_checkorder+0xddc) > sp = 0xdc20caf8 fp = 0xdc20cb48 > r4 = 0xc049fa8a > witness_checkorder() at witness_checkorder+0xddc > pc = 0xc0282df8 lr = 0xc022050c (__mtx_lock_spin_flags+0xc4) > sp = 0xdc20cb50 fp = 0xdc20cb70 > r4 = 0x00000000 r5 = 0xc0580a84 > r6 = 0xc25d7c20 r7 = 0xc25d7c30 > r8 = 0x00000000 r9 = 0x0000005c > r10 = 0xc049fb56 > __mtx_lock_spin_flags() at __mtx_lock_spin_flags+0xc4 > pc = 0xc022050c lr = 0xc014e9a4 (uart_cnputc+0x44) > sp = 0xdc20cb78 fp = 0xdc20cb88 > r4 = 0x0000006c r5 = 0xc0580a84 > r6 = 0xc05908a0 r7 = 0xc0581700 > r8 = 0xc055d590 r9 = 0xc05816e0 > r10 = 0xdc20ccf0 > uart_cnputc() at uart_cnputc+0x44 > pc = 0xc014e9a4 lr = 0xc01eb6b0 (cnputc+0x80) > sp = 0xdc20cb90 fp = 0xdc20cba8 > r4 = 0x0000006c r5 = 0xc0551c30 > r6 = 0xc05908a0 > cnputc() at cnputc+0x80 > pc = 0xc01eb6b0 lr = 0xc026e6ec (putchar+0x194) > sp = 0xdc20cbb0 fp = 0xdc20cc18 > r4 = 0x00000005 r5 = 0xdc20ccf0 > r6 = 0x0000006c r7 = 0x00000000 > r8 = 0xc06f52b4 r9 = 0xc026e558 > putchar() at putchar+0x194 > pc = 0xc026e6ec lr = 0xc026d53c (kvprintf+0xb0) > sp = 0xdc20cc20 fp = 0xdc20ccd8 > r4 = 0xc04bc4c4 r5 = 0x00000000 > r6 = 0x00000000 r7 = 0x00000000 > r8 = 0xc06f52b4 r9 = 0xc026e558 > r10 = 0xdc20ccf0 > kvprintf() at kvprintf+0xb0 > pc = 0xc026d53c lr = 0xc026ec58 (printf+0x50) > sp = 0xdc20cce0 fp = 0xdc20cd10 > r4 = 0xc2446da8 r5 = 0xc2446a68 > r6 = 0x00000000 r7 = 0xc06c394c > r8 = 0xc06f52b4 r9 = 0x00000001 > r10 = 0xc06c395b > printf() at printf+0x50 > pc = 0xc026ec58 lr = 0xc0282b58 (witness_checkorder+0xb3c) > sp = 0xdc20cd28 fp = 0xdc20cd78 > witness_checkorder() at witness_checkorder+0xb3c > pc = 0xc0282b58 lr = 0xc022050c (__mtx_lock_spin_flags+0xc4) > sp = 0xdc20cd80 fp = 0xdc20cda0 > r4 = 0x00000000 r5 = 0x00000000 > r6 = 0xc059198c r7 = 0xc059199c > r8 = 0x00000000 r9 = 0x000000f0 > r10 = 0xc04ba67a > __mtx_lock_spin_flags() at __mtx_lock_spin_flags+0xc4 > pc = 0xc022050c lr = 0xc02751a4 (sleepq_lock+0x34) > sp = 0xdc20cda8 fp = 0xdc20cda8 > r4 = 0xc2582960 r5 = 0x00000000 > r6 = 0xc0580394 r7 = 0x00000000 > r8 = 0xc2584c80 r9 = 0x00000000 > r10 = 0xc0580390 > sleepq_lock() at sleepq_lock+0x34 > pc = 0xc02751a4 lr = 0xc023c4c0 (msleep_spin_sbt+0x80) > sp = 0xdc20cdb0 fp = 0xdc20cdf0 > msleep_spin_sbt() at msleep_spin_sbt+0x80 > pc = 0xc023c4c0 lr = 0xc0147458 (random_kthread+0x270) > sp = 0xdc20cdf8 fp = 0xdc20ce38 > r4 = 0xc06f3c1c r5 = 0x00000000 > r6 = 0xc049f1d1 r7 = 0x00000000 > r8 = 0x00000000 r9 = 0x00000000 > r10 = 0xc0580390 > random_kthread() at random_kthread+0x270 > pc = 0xc0147458 lr = 0xc02033f0 (fork_exit+0x88) > sp = 0xdc20ce40 fp = 0xdc20ce58 > r4 = 0xc2584c80 r5 = 0xc2582960 > r6 = 0xc01471e8 r7 = 0x00000000 > r8 = 0xdc20ce60 r9 = 0x00000000 > r10 = 0x00000000 > fork_exit() at fork_exit+0x88 > pc = 0xc02033f0 lr = 0xc0475cec (fork_trampoline+0x14) > sp = 0xdc20ce60 fp = 0x00000000 > r4 = 0xc01471e8 r5 = 0x00000000 > r6 = 0xc0c0c0c0 r7 = 0xc0c0c0c0 > r8 = 0x00000000 > fork_trampoline() at fork_trampoline+0x14 > pc = 0xc0475cec lr = 0xc0475cec (fork_trampoline+0x14) > sp = 0xdc20ce60 fp = 0x00000000 > Unable to unwind further > lock order reversal: > 1st 0xc06f3c0c entropy harvest mutex (entropy harvest mutex) @ /usr/home/martin/Rasperry/head/sys/dev/random/randomdev_soft.c:242 > 2nd 0xc059198c sleepq chain (sleepq chain) @ /usr/home/martin/Rasperry/head/sys/kern/subr_sleepqueue.c:240 > KDB: stack backtrace: > db_trace_self() at db_trace_self > pc = 0xc04652cc lr = 0xc012e474 (db_trace_self_wrapper+0x30) > sp = 0xdc20cbf8 fp = 0xdc20cd10 > r10 = 0xc06f3c0c > db_trace_self_wrapper() at db_trace_self_wrapper+0x30 > pc = 0xc012e474 lr = 0xc0268974 (kdb_backtrace+0x38) > sp = 0xdc20cd18 fp = 0xdc20cd20 > r4 = 0xc05908a4 r5 = 0xc04ba67d > r6 = 0xc04bd04d r7 = 0xc049f1d4 > kdb_backtrace() at kdb_backtrace+0x38 > pc = 0xc0268974 lr = 0xc0282df8 (witness_checkorder+0xddc) > sp = 0xdc20cd28 fp = 0xdc20cd78 > r4 = 0xc04ba662 > witness_checkorder() at witness_checkorder+0xddc > pc = 0xc0282df8 lr = 0xc022050c (__mtx_lock_spin_flags+0xc4) > sp = 0xdc20cd80 fp = 0xdc20cda0 > r4 = 0x00000000 r5 = 0x00000000 > r6 = 0xc059198c r7 = 0xc059199c > r8 = 0x00000000 r9 = 0x000000f0 > r10 = 0xc04ba67a > __mtx_lock_spin_flags() at __mtx_lock_spin_flags+0xc4 > pc = 0xc022050c lr = 0xc02751a4 (sleepq_lock+0x34) > sp = 0xdc20cda8 fp = 0xdc20cda8 > r4 = 0xc2582960 r5 = 0x00000000 > r6 = 0xc0580394 r7 = 0x00000000 > r8 = 0xc2584c80 r9 = 0x00000000 > r10 = 0xc0580390 > sleepq_lock() at sleepq_lock+0x34 > pc = 0xc02751a4 lr = 0xc023c4c0 (msleep_spin_sbt+0x80) > sp = 0xdc20cdb0 fp = 0xdc20cdf0 > msleep_spin_sbt() at msleep_spin_sbt+0x80 > pc = 0xc023c4c0 lr = 0xc0147458 (random_kthread+0x270) > sp = 0xdc20cdf8 fp = 0xdc20ce38 > r4 = 0xc06f3c1c r5 = 0x00000000 > r6 = 0xc049f1d1 r7 = 0x00000000 > r8 = 0x00000000 r9 = 0x00000000 > r10 = 0xc0580390 > random_kthread() at random_kthread+0x270 > pc = 0xc0147458 lr = 0xc02033f0 (fork_exit+0x88) > sp = 0xdc20ce40 fp = 0xdc20ce58 > r4 = 0xc2584c80 r5 = 0xc2582960 > r6 = 0xc01471e8 r7 = 0x00000000 > r8 = 0xdc20ce60 r9 = 0x00000000 > r10 = 0x00000000 > fork_exit() at fork_exit+0x88 > pc = 0xc02033f0 lr = 0xc0475cec (fork_trampoline+0x14) > sp = 0xdc20ce60 fp = 0x00000000 > r4 = 0xc01471e8 r5 = 0x00000000 > r6 = 0xc0c0c0c0 r7 = 0xc0c0c0c0 > r8 = 0x00000000 > fork_trampoline() at fork_trampoline+0x14 > pc = 0xc0475cec lr = 0xc0475cec (fork_trampoline+0x14) > sp = 0xdc20ce60 fp = 0x00000000 > Unable to unwind further > usbus0: 480Mbps High Speed USB v2.0 > ugen0.1: at usbus0 > uhub0: on usbus0 > uhub0: 1 port with 1 removable, self powered > mmcsd0: 8GB at mmc0 50.0MHz/4bit/65535-block > WARNING: WITNESS option enabled, expect reduced performance. > WARNING: DIAGNOSTIC option enabled, expect reduced performance. > mmcsd0: Error indicated: 1 Timeout > mmcsd0: Error indicated: 1 Timeout > Root mount waiting for: usbus0 > ugen0.2: at usbus0 > uhub1: on usbus0 > uhub1: MTT enabled > Root mount waiting for: usbus0 > uhub1: 3 ports with 2 removable, self powered > Root mount waiting for: usbus0 > ugen0.3: at usbus0 > smsc0: on usbus0 > Trying to mount root from ufs:/dev/mmcsd0s2a [rw,noatime]... > mountroot: waiting for device /dev/mmcsd0s2a ... > smsc0: chip 0xec00, rev. 0002 > miibus0: on smsc0 > ukphy0: PHY 1 on miibus0 > ukphy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto > ue0: on smsc0 > ue0: Ethernet address: b8:27:eb:1d:b7:5a > Mounting from ufs:/dev/mmcsd0s2a failed with error 19. > > Loader variables: > vfs.root.mountfrom=ufs:/dev/mmcsd0s2a > vfs.root.mountfrom.options=rw,noatime > > Manual root filesystem specification: > : [options] > Mount using filesystem > and with the specified (optional) option list. > > eg. ufs:/dev/da0s1a > zfs:tank > cd9660:/dev/acd0 ro > (which is equivalent to: mount -t cd9660 -o ro /dev/acd0 /) > > ? List valid disk boot devices > . Yield 1 second (for background tasks) > Abort manual input > > mountroot> > > >Release-Note: > >Audit-Trail: > >Unformatted: A little background that may or may not be helpful in investigating this problem... We have long had a problem with mysterious sdcard timeout errors on RPi that doesn't happen on other hardware with sdhci controllers. Until now, it was thought that these timeouts always occurred shortly after the controller was initialized by the OS. The timeouts would affect the early card-detection sequences; we worked around them by adding automatic retries to the mmc code that identifies and initializes cards. This error appears to be a timeout that occurs after the card init sequences are done (the errors are reported by mmcsd0, not mmc0). From owner-freebsd-arm@FreeBSD.ORG Wed Aug 28 12:41: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 186C5616; Wed, 28 Aug 2013 12:41:34 +0000 (UTC) (envelope-from lists.br@gmail.com) Received: from mail-we0-x231.google.com (mail-we0-x231.google.com [IPv6:2a00:1450:400c:c03::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 7B82C247F; Wed, 28 Aug 2013 12:41:33 +0000 (UTC) Received: by mail-we0-f177.google.com with SMTP id q55so5101243wes.36 for ; Wed, 28 Aug 2013 05:41:31 -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=iY5/fS002OFI3jR0J8VIZcYl4UsPIUyLrPTcjWdGpvk=; b=S6Tc7wbYCmeib+ebO37IOdmbwubuCrDUdSnYqsNQfniFIrJEGS5Y/rXSY224vqiVmN uIRrQGaMm3wrs3c0llVz3QpDIZVAXTpllzo04i4wnW7jRinCKczMBDqqhnLHyPfxUHpv jlcBzWTtt8qhFyaV5UCjlSUfZpkwGqds8FjK8t2WZOx/RAeflnIkP46Rn5tNSNpbyLia Ty9yyBqlltIdVGpyI9j6/xFOeIIEAKwz4cw1LD6eLtrL9Gxy9f3IS3v7sVtoiqw42kx9 RtcmhjRIq6Vx3tIfN+X3Rlw5w+OpvEkSg12T0sP1a7CS9hWmzoFjGtGjBULQyvaADJH5 oFbA== MIME-Version: 1.0 X-Received: by 10.194.134.168 with SMTP id pl8mr1694577wjb.74.1377693691811; Wed, 28 Aug 2013 05:41:31 -0700 (PDT) Received: by 10.216.75.140 with HTTP; Wed, 28 Aug 2013 05:41:31 -0700 (PDT) In-Reply-To: <201308281230.r7SCU0k5093956@freefall.freebsd.org> References: <201308281230.r7SCU0k5093956@freefall.freebsd.org> Date: Wed, 28 Aug 2013 09:41:31 -0300 Message-ID: Subject: Re: arm/181601: Sporadic failure of root mount on ARM/Raspberry From: Luiz Otavio O Souza To: Ian Lepore 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: Wed, 28 Aug 2013 12:41:34 -0000 On 28 August 2013 09:30, Ian Lepore wrote: [...] > mmcsd0: 8GB at mmc0 50.0MHz/4bit/65535-block > WARNING: WITNESS option enabled, expect reduced performance. > WARNING: DIAGNOSTIC option enabled, expect reduced performance. > mmcsd0: Error indicated: 1 Timeout > mmcsd0: Error indicated: 1 Timeout [...] > > We have long had a problem with mysterious sdcard timeout errors on RPi > that doesn't happen on other hardware with sdhci controllers. Until > now, it was thought that these timeouts always occurred shortly after > the controller was initialized by the OS. The timeouts would affect the > early card-detection sequences; we worked around them by adding > automatic retries to the mmc code that identifies and initializes cards. > > This error appears to be a timeout that occurs after the card init > sequences are done (the errors are reported by mmcsd0, not mmc0). > Yes, i've seen this as well and for me, every time it fails it thinks my SD is HS capable while it isn't. This make it fail later. Setting hw.bcm2835.sdhci.hs=0 on loader.conf works fine as a workaround. Luiz From owner-freebsd-arm@FreeBSD.ORG Wed Aug 28 15: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 300C5BBC for ; Wed, 28 Aug 2013 15:53:33 +0000 (UTC) (envelope-from 01aurelien@gmail.com) Received: from mail-ea0-x231.google.com (mail-ea0-x231.google.com [IPv6:2a00:1450:4013:c01::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id B9C1A231D for ; Wed, 28 Aug 2013 15:53:32 +0000 (UTC) Received: by mail-ea0-f177.google.com with SMTP id f15so3016714eak.22 for ; Wed, 28 Aug 2013 08:53:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:subject:from:to:date:content-type:mime-version :content-transfer-encoding; bh=kuYmjb/yBdB3Zxf99+5w76Y5awBID/h8ND63MgMI8fo=; b=xugbbZIulTNH6JkV6R0/zGIs0IPNS5e8MYWSTt7HmI1EcKQf8nmr582jZS/LYWGSwv 0Z37xpDEJqSw/lGcLh94SqXG/TpgKNtEv1XkNyOKhHEBaK137rFsw/h36nTizuSgxC/v xrKnkYGoHtWnzUk4m14IxcNrDNgLylBcowCWAZ4JPjV9i7r14EmOF+uktlKMDOQr/PJX 3rVgGevNrTD0VHPGA/iWqSmsPSOfVbvkez2eqv1NnE/+qRqM9RUP5DQGGpfKiTAYYqli wVtrsH2U6kOnBPmQlOZmN/xGEfGs+Y1C6bvrFX+325K/9qKikcU6jUWV3P7E5scoki8v R4dw== X-Received: by 10.15.76.73 with SMTP id m49mr2068657eey.91.1377705211135; Wed, 28 Aug 2013 08:53:31 -0700 (PDT) Received: from [128.141.246.180] (pb-d-128-141-246-180.cern.ch. [128.141.246.180]) by mx.google.com with ESMTPSA id f49sm38476993eec.7.1969.12.31.16.00.00 (version=SSLv3 cipher=RC4-SHA bits=128/128); Wed, 28 Aug 2013 08:53:30 -0700 (PDT) Message-ID: <1377705113.23901.8.camel@pandabook> Subject: unbound compilation issue From: Aurelien Martin <01aurelien@gmail.com> To: freebsd-arm@freebsd.org Date: Wed, 28 Aug 2013 17:51:53 +0200 Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.4.4-3 Mime-Version: 1.0 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, 28 Aug 2013 15:53:33 -0000 Dear all, my first in mailing list :) I have a compilation failure for "unbound" (gettext seems involved) http://pastebin.com/DUmVpZ5R rpi B with: FreeBSD raspberry-pi 10.0-CURRENT FreeBSD 10.0-CURRENT #84 r252209M: Thu Jun 27 09:09:14 EDT 2013 I already ask to #freebsd channel they advice me to modify my make.conf: CC=gcc42 CXX=g++42 CPP=cpp42 But almost the same errors: http://pastebin.com/jstWRMSY Thanks by advance Aurelien From owner-freebsd-arm@FreeBSD.ORG Wed Aug 28 16:36: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 CB0B47E0 for ; Wed, 28 Aug 2013 16:36:07 +0000 (UTC) (envelope-from mlfbsd@kanar.ci0.org) Received: from kanar.ci0.org (unknown [IPv6:2a01:e0b:1:150:ca0a:a9ff:fef1:a4c9]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 6D6DC26BF for ; Wed, 28 Aug 2013 16:36:07 +0000 (UTC) Received: from kanar.ci0.org (pluxor@localhost [127.0.0.1]) by kanar.ci0.org (8.14.5/8.14.5) with ESMTP id r7SGZjw0055142; Wed, 28 Aug 2013 18:35:45 +0200 (CEST) (envelope-from mlfbsd@kanar.ci0.org) Received: (from mlfbsd@localhost) by kanar.ci0.org (8.14.5/8.14.5/Submit) id r7SGZj1H055141; Wed, 28 Aug 2013 18:35:45 +0200 (CEST) (envelope-from mlfbsd) Date: Wed, 28 Aug 2013 18:35:45 +0200 From: Olivier Houchard To: Aurelien Martin <01aurelien@gmail.com> Subject: Re: unbound compilation issue Message-ID: <20130828163545.GA55072@ci0.org> References: <1377705113.23901.8.camel@pandabook> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1377705113.23901.8.camel@pandabook> User-Agent: Mutt/1.5.21 (2010-09-15) 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, 28 Aug 2013 16:36:07 -0000 Hi Aurelien, On Wed, Aug 28, 2013 at 05:51:53PM +0200, Aurelien Martin wrote: > Dear all, my first in mailing list :) > > I have a compilation failure for "unbound" (gettext seems involved) > http://pastebin.com/DUmVpZ5R > > rpi B with: FreeBSD raspberry-pi 10.0-CURRENT FreeBSD 10.0-CURRENT #84 > r252209M: Thu Jun 27 09:09:14 EDT 2013 > > I already ask to #freebsd channel they advice me to modify my make.conf: > CC=gcc42 > CXX=g++42 > CPP=cpp42 > That should probably just be gcc, g++ and cpp. > But almost the same errors: http://pastebin.com/jstWRMSY Did you run make clean ? It seems it still tries to use clang as the compiler. Regards, Olivier From owner-freebsd-arm@FreeBSD.ORG Wed Aug 28 17:01:03 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 C0C0AE5E; Wed, 28 Aug 2013 17:01:03 +0000 (UTC) (envelope-from mattia.rossi.mate@gmail.com) Received: from mail-ee0-x229.google.com (mail-ee0-x229.google.com [IPv6:2a00:1450:4013:c00::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 2C1FC281E; Wed, 28 Aug 2013 17:01:03 +0000 (UTC) Received: by mail-ee0-f41.google.com with SMTP id d17so3101965eek.14 for ; Wed, 28 Aug 2013 10:01:01 -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=HTpaqFl/k2di+8CBqwFwtJt2XebrjkQGwFiAkBRlSa4=; b=vfmWQj+o/paRFenaKHO6jwJiEGchwranykGIJuSQYrIg8tEJ0NGdKBVvZJzqAuZoU6 2tLQ46APW1u0aRQITsE/YzsYHatrDyLioSU013y0AVhh9C1gVKBFfpyEPwUCCOgZDP3I SkKe6md+JxulOcJlbbO60bzcn32HLCnNzZ9wiOqCwg7fGzfpva/Wrqph8DMY3HcbVps9 u7MjmZIZOEN+6Ad1UeOkxPtFg2MVYvXHZR1i//9DWTZ+HMIHAKKkUWJDUs+U10IuKu6V Gt4GBkTe+LOKUbWnn18a3FGR1FSpMVWZxZihTokqPXp6+UBRUccqLQn15b4JpgRTzMyZ q5DA== X-Received: by 10.15.86.11 with SMTP id h11mr3048377eez.80.1377709261420; Wed, 28 Aug 2013 10:01:01 -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 p5sm38955603eeg.5.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 28 Aug 2013 10:01:00 -0700 (PDT) Message-ID: <521E2CCB.4070804@gmail.com> Date: Wed, 28 Aug 2013 19:00:59 +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: Ian Lepore Subject: Re: Reminder: Removal of WITHOUT_ARM_EABI References: <20130820091527.42127170@bender.Home> <1377271598.1111.78.camel@revolution.hippie.lan> In-Reply-To: <1377271598.1111.78.camel@revolution.hippie.lan> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-arm@FreeBSD.org 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: Wed, 28 Aug 2013 17:01:03 -0000 Well, here's my input on this: I've got around building a working kernel using CLANG (added option SCTP which fixed the alignment issue) and then got stuck at entropy harvesting. ^T doesn't do anything, nor does ^C. So I rebuilt everything with -DWITHOUT_ARM_EABI. There I get: Process (pid 1) got signal 11 Does a CLANG compiled world without EABI even work? Cheers, Mat On 23/08/13 17:26, Ian Lepore wrote: > On Tue, 2013-08-20 at 09:15 +0100, Andrew Turner wrote: >> I am planning on removing WITHOUT_ARM_EABI before 10.0 is released. As >> this is planned on happening soon it this change is likely to happen >> within the next two weeks, after a short heads up. >> >> This is a reminder for people who have not yet moved to the ARM EABI to >> do so now as their build will break when this option is removed. >> > It turns out that on DreamPlug (armv5te) the unit won't boot all the way > to multiuser mode with EABI, building with gcc or clang. I first > discovered this a few days ago when I realized I was still building with > OABI on dreamplug and tried to switch. I tried going back to a revision > in late July but that didn't make any difference. The before getting > any further with bisecting I heard from Ilya Bakulin on irc that the > problems I'm seeing (hanging in rc.d/initrandom and rc.d/var) go back to > at least April. > > The rc.d/initrandom problem seems to be while running the 'df' command > to "generate entropy." In rc.d/var the problem is while running newfs > on /dev/md0, and I can more readily confirm that -- if I use ^C to get > past the hangs in rc.d processing it'll limp its way to multiuser mode, > and if you manually try to "newfs /dev/md0" it definitely hangs the same > way. When it's hung in that state, a ^T gives no info, but a ^C does > break out of the hang. I've been unable to get any more info about > how/why it's hung. > > I can understand a desire to not let any 10.0 release get into the wild > with OABI support, but I'm not sure that removing the ability to even > try OABI to see if it fixes a problem is a good idea. EABI just doesn't > have enough testing to declare that it's solid (because clearly it's not > yet solid). Can we declare that OABI isn't supported without removing > the ability to fall back to it for testing purposes? I wouldn't mind if > enabling it requires something like WITH_UNSUPPORTED_OABI_FOR_TESTING. > > -- Ian > > > _______________________________________________ > freebsd-arm@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" From owner-freebsd-arm@FreeBSD.ORG Wed Aug 28 18:42: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 A44F9123; Wed, 28 Aug 2013 18:42:16 +0000 (UTC) (envelope-from mailinglists@martinlaabs.de) Received: from relay04.alfahosting-server.de (relay04.alfahosting-server.de [109.237.142.240]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 5DA4D2E74; Wed, 28 Aug 2013 18:42:16 +0000 (UTC) Received: by relay04.alfahosting-server.de (Postfix, from userid 1001) id AE3B732C079C; Wed, 28 Aug 2013 20:42:07 +0200 (CEST) X-Spam-DCC: : X-Spam-Level: X-Spam-Status: No, score=0.0 required=7.0 tests=BAYES_50 autolearn=disabled version=3.2.5 Received: from alfa3018.alfahosting-server.de (alfa3018.alfahosting-server.de [109.237.140.30]) by relay04.alfahosting-server.de (Postfix) with ESMTPS id 64E3232C083C; Wed, 28 Aug 2013 20:42:06 +0200 (CEST) Received: from [192.168.1.55] (p54B30A87.dip0.t-ipconnect.de [84.179.10.135]) by alfa3018.alfahosting-server.de (Postfix) with ESMTPSA id D0CE2515DE3D; Wed, 28 Aug 2013 20:42:05 +0200 (CEST) Message-ID: <521E447C.9000505@martinlaabs.de> Date: Wed, 28 Aug 2013 20:42:04 +0200 From: Martin Laabs User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130809 Thunderbird/17.0.8 MIME-Version: 1.0 To: Ian Lepore Subject: Re: arm/181602: Raspberry PI kernel panic after DHCP References: <201308280544.r7S5id9t094480@oldred.freebsd.org> <1377691823.1111.235.camel@revolution.hippie.lan> In-Reply-To: <1377691823.1111.235.camel@revolution.hippie.lan> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Status: No X-Virus-Checker-Version: clamassassin 1.2.4 with ClamAV 0.97.3/17762/Wed Aug 28 18:42:58 2013 Cc: freebsd-arm@freebsd.org, freebsd-gnats-submit@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: Wed, 28 Aug 2013 18:42:16 -0000 On 28.08.2013 14:10, Ian Lepore wrote: > On Wed, 2013-08-28 at 05:44 +0000, Martin Laabs wrote: >>> Number: 181602 >>> Category: arm >>> Synopsis: Raspberry PI kernel panic after DHCP [...] > This problem was caused by recent changes to the layout of struct mbuf > and the structures embedded within it. Fixed in r254973. OK. I can confirm this for the Raspberry-Pi. Running a r254984 So from my side it is OK to close the bug. Best regards, Martin Laabs From owner-freebsd-arm@FreeBSD.ORG Wed Aug 28 18:50:02 2013 Return-Path: Delivered-To: freebsd-arm@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 4EB9E430 for ; Wed, 28 Aug 2013 18:50:02 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 3A7A32F00 for ; Wed, 28 Aug 2013 18:50:02 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r7SIo1cr087600 for ; Wed, 28 Aug 2013 18:50:01 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r7SIo1JM087599; Wed, 28 Aug 2013 18:50:01 GMT (envelope-from gnats) Date: Wed, 28 Aug 2013 18:50:01 GMT Message-Id: <201308281850.r7SIo1JM087599@freefall.freebsd.org> To: freebsd-arm@FreeBSD.org Cc: From: Martin Laabs Subject: Re: arm/181602: Raspberry PI kernel panic after DHCP X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Martin Laabs List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Aug 2013 18:50:02 -0000 The following reply was made to PR arm/181602; it has been noted by GNATS. From: Martin Laabs To: Ian Lepore Cc: freebsd-gnats-submit@FreeBSD.org, freebsd-arm@freebsd.org, freebsd-current@freebsd.org Subject: Re: arm/181602: Raspberry PI kernel panic after DHCP Date: Wed, 28 Aug 2013 20:42:04 +0200 On 28.08.2013 14:10, Ian Lepore wrote: > On Wed, 2013-08-28 at 05:44 +0000, Martin Laabs wrote: >>> Number: 181602 >>> Category: arm >>> Synopsis: Raspberry PI kernel panic after DHCP [...] > This problem was caused by recent changes to the layout of struct mbuf > and the structures embedded within it. Fixed in r254973. OK. I can confirm this for the Raspberry-Pi. Running a r254984 So from my side it is OK to close the bug. Best regards, Martin Laabs From owner-freebsd-arm@FreeBSD.ORG Wed Aug 28 22:44:18 2013 Return-Path: Delivered-To: freebsd-arm@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 72FFC62E; Wed, 28 Aug 2013 22:44:18 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 48A652DFF; Wed, 28 Aug 2013 22:44:18 +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 r7SMiIjO033709; Wed, 28 Aug 2013 22:44:18 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r7SMiFeo033708; Wed, 28 Aug 2013 22:44:15 GMT (envelope-from linimon) Date: Wed, 28 Aug 2013 22:44:15 GMT Message-Id: <201308282244.r7SMiFeo033708@freefall.freebsd.org> To: info@martinlaabs.de, linimon@FreeBSD.org, freebsd-arm@FreeBSD.org From: linimon@FreeBSD.org Subject: Re: arm/181602: Raspberry PI kernel panic after DHCP 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, 28 Aug 2013 22:44:18 -0000 Synopsis: Raspberry PI kernel panic after DHCP State-Changed-From-To: open->closed State-Changed-By: linimon State-Changed-When: Wed Aug 28 22:43:28 UTC 2013 State-Changed-Why: Fixed in r254973. http://www.freebsd.org/cgi/query-pr.cgi?pr=181602 From owner-freebsd-arm@FreeBSD.ORG Thu Aug 29 07:37: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 3C18E942 for ; Thu, 29 Aug 2013 07:37:41 +0000 (UTC) (envelope-from 01aurelien@gmail.com) Received: from mail-ee0-x22b.google.com (mail-ee0-x22b.google.com [IPv6:2a00:1450:4013:c00::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id C23452B6B for ; Thu, 29 Aug 2013 07:37:40 +0000 (UTC) Received: by mail-ee0-f43.google.com with SMTP id e52so39934eek.30 for ; Thu, 29 Aug 2013 00:37:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:subject:from:to:cc:date:in-reply-to:references :content-type:mime-version:content-transfer-encoding; bh=L8Tc9lvU3nq11L+6rFsJaIg/OQFoBFr8w7Pk2ZleHkM=; b=JvX1JzG+VaFlBortSEFtgKsDsDTsDDZX2wtKQMiAPQSnt9nyhJzFTc135ej5LPXNjT xK/2m+uJ7IEFB2gfdmfa7yLZKTpyhk50kgBcTtqqzMBJk883sTzzVOcsZMjwHiDT6iN3 p5IBhiadM13Sdgc4VtgdhF0TclX7lLuOpPHEZgrea/5HW2WDLHf4oKAB5wqGxcSlYBo7 if7klyrwZgD07jvqW0CQSsQjFLqBRU5R4km720t3Q5Owlw3tRBLWGj5grFrc+KdrU4cR 6dhDZ8QD58wEA5V7nRuyfRKHeKuAD2tGQuI//zubvofdmamVeBBrtCcZANUr5c+9MjNk Midw== X-Received: by 10.15.63.142 with SMTP id m14mr219045eex.106.1377761859053; Thu, 29 Aug 2013 00:37:39 -0700 (PDT) Received: from [128.141.43.169] (pb-d-128-141-43-169.cern.ch. [128.141.43.169]) by mx.google.com with ESMTPSA id m54sm43681880eex.2.1969.12.31.16.00.00 (version=SSLv3 cipher=RC4-SHA bits=128/128); Thu, 29 Aug 2013 00:37:38 -0700 (PDT) Message-ID: <1377761762.6953.7.camel@pandabook> Subject: Re: unbound compilation issue rpi From: Aurelien Martin <01aurelien@gmail.com> To: Olivier Houchard Date: Thu, 29 Aug 2013 09:36:02 +0200 In-Reply-To: <20130828163545.GA55072@ci0.org> References: <1377705113.23901.8.camel@pandabook> <20130828163545.GA55072@ci0.org> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.4.4-3 Mime-Version: 1.0 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, 29 Aug 2013 07:37:41 -0000 Hi Olivier, I did "make clean" http://pastebin.com/ki0c7MWf A new issue with "make install", it's seems related to gettext http://pastebin.com/g9K6V6EQ The "make install" advice me to sent the following attachment to autotools@FreeBSD.org [maintainer]. Should I ? http://pastebin.com/JpyRFshY p.s: mailing list prefer pastebin log or attachment ? Aurelien On Wed, 2013-08-28 at 18:35 +0200, Olivier Houchard wrote: > Hi Aurelien, > > On Wed, Aug 28, 2013 at 05:51:53PM +0200, Aurelien Martin wrote: > > Dear all, my first in mailing list :) > > > > I have a compilation failure for "unbound" (gettext seems involved) > > http://pastebin.com/DUmVpZ5R > > > > rpi B with: FreeBSD raspberry-pi 10.0-CURRENT FreeBSD 10.0-CURRENT #84 > > r252209M: Thu Jun 27 09:09:14 EDT 2013 > > > > I already ask to #freebsd channel they advice me to modify my make.conf: > > CC=gcc42 > > CXX=g++42 > > CPP=cpp42 > > > > That should probably just be gcc, g++ and cpp. > > > But almost the same errors: http://pastebin.com/jstWRMSY > > Did you run make clean ? It seems it still tries to use clang as the compiler. > > Regards, > > Olivier From owner-freebsd-arm@FreeBSD.ORG Thu Aug 29 12:45: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 6FF25718 for ; Thu, 29 Aug 2013 12:45:42 +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 311982414 for ; Thu, 29 Aug 2013 12:45:41 +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 r7TCix2P009643; Thu, 29 Aug 2013 08:44:59 -0400 Received: from auth3.smtp.vt.edu (auth3.smtp.vt.edu [198.82.161.152]) by mr2.cc.vt.edu (8.14.4/8.14.4) with ESMTP id r7TCiw3G001537; Thu, 29 Aug 2013 08:44:58 -0400 Received: from pmather.tower.lib.vt.edu (pmather.tower.lib.vt.edu [128.173.51.28]) (authenticated bits=0) by auth3.smtp.vt.edu (8.13.8/8.13.8) with ESMTP id r7TCiwFs028368 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 29 Aug 2013 08:44:58 -0400 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Subject: Re: unbound compilation issue rpi From: Paul Mather In-Reply-To: <1377761762.6953.7.camel@pandabook> Date: Thu, 29 Aug 2013 08:44:57 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1377705113.23901.8.camel@pandabook> <20130828163545.GA55072@ci0.org> <1377761762.6953.7.camel@pandabook> To: Aurelien Martin <01aurelien@gmail.com> 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: Thu, 29 Aug 2013 12:45:42 -0000 On Aug 29, 2013, at 3:36 AM, Aurelien Martin <01aurelien@gmail.com> = wrote: > Hi Olivier, >=20 > I did "make clean" > http://pastebin.com/ki0c7MWf >=20 > A new issue with "make install", it's seems related to gettext > http://pastebin.com/g9K6V6EQ I'd say this snippet from the pastebin log is a big clue to your = problem: =3D=3D=3D=3D=3D checking for gcc... gcc42 checking whether the C compiler works... no configure: error: in = `/usr/ports/devel/gettext/work/gettext-0.18.3/gettext-runtime': configure: error: C compiler cannot create executables =3D=3D=3D=3D=3D As someone else asked previously, why are you using gcc42 instead of the = built-in gcc? Is the gcc42 port known to work correctly on arm? You might try this instead: CC=3Dgcc CXX=3Dg++ CPP=3Dgcpp I would have said the built-in compiler has a better track record of = working than any other on FreeBSD/arm, but now I'm not sure that is even = true with the move to EABI. Does gcc on arm support EABI, or just = clang? The seas are mighty rough on FreeBSD/arm nowadays... Cheers, Paul. >=20 > The "make install" advice me to sent the following attachment to > autotools@FreeBSD.org [maintainer]. Should I ? >=20 > http://pastebin.com/JpyRFshY >=20 > p.s: mailing list prefer pastebin log or attachment ? >=20 > Aurelien >=20 >=20 >=20 >=20 > On Wed, 2013-08-28 at 18:35 +0200, Olivier Houchard wrote: >> Hi Aurelien, >>=20 >> On Wed, Aug 28, 2013 at 05:51:53PM +0200, Aurelien Martin wrote: >>> Dear all, my first in mailing list :) >>>=20 >>> I have a compilation failure for "unbound" (gettext seems involved) >>> http://pastebin.com/DUmVpZ5R=20 >>>=20 >>> rpi B with: FreeBSD raspberry-pi 10.0-CURRENT FreeBSD 10.0-CURRENT = #84 >>> r252209M: Thu Jun 27 09:09:14 EDT 2013=20 >>>=20 >>> I already ask to #freebsd channel they advice me to modify my = make.conf: >>> CC=3Dgcc42=20 >>> CXX=3Dg++42=20 >>> CPP=3Dcpp42 >>>=20 >>=20 >> That should probably just be gcc, g++ and cpp. >>=20 >>> But almost the same errors: http://pastebin.com/jstWRMSY >>=20 >> Did you run make clean ? It seems it still tries to use clang as the = compiler. >>=20 >> Regards, >>=20 >> Olivier >=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" >=20 From owner-freebsd-arm@FreeBSD.ORG Thu Aug 29 14:15: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 94780273 for ; Thu, 29 Aug 2013 14:15:43 +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 08F382AEC for ; Thu, 29 Aug 2013 14:15:42 +0000 (UTC) Received: from cpsps-ews09.kpnxchange.com ([10.94.84.176]) by cpsmtpb-ews04.kpnxchange.com with Microsoft SMTPSVC(7.5.7601.17514); Thu, 29 Aug 2013 16:15:36 +0200 Received: from CPSMTPM-TLF101.kpnxchange.com ([195.121.3.4]) by cpsps-ews09.kpnxchange.com with Microsoft SMTPSVC(7.5.7601.17514); Thu, 29 Aug 2013 16:15:36 +0200 Received: from sjakie.klop.ws ([212.182.167.131]) by CPSMTPM-TLF101.kpnxchange.com with Microsoft SMTPSVC(7.5.7601.17514); Thu, 29 Aug 2013 16:15:36 +0200 Received: from 212-182-167-131.ip.telfort.nl (localhost [127.0.0.1]) by sjakie.klop.ws (Postfix) with ESMTP id 2B2DFC3E1 for ; Thu, 29 Aug 2013 16:15:31 +0200 (CEST) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes To: freebsd-arm@freebsd.org Subject: Re: Reminder: Removal of WITHOUT_ARM_EABI References: <20130820091527.42127170@bender.Home> <1377271598.1111.78.camel@revolution.hippie.lan> Date: Thu, 29 Aug 2013 16:15:31 +0200 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Ronald Klop" Message-ID: In-Reply-To: <1377271598.1111.78.camel@revolution.hippie.lan> User-Agent: Opera Mail/12.16 (FreeBSD) X-OriginalArrivalTime: 29 Aug 2013 14:15:36.0639 (UTC) FILETIME=[3B5574F0:01CEA4C2] 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, 29 Aug 2013 14:15:43 -0000 On Fri, 23 Aug 2013 17:26:38 +0200, Ian Lepore wrote: > On Tue, 2013-08-20 at 09:15 +0100, Andrew Turner wrote: >> I am planning on removing WITHOUT_ARM_EABI before 10.0 is released. As >> this is planned on happening soon it this change is likely to happen >> within the next two weeks, after a short heads up. >> >> This is a reminder for people who have not yet moved to the ARM EABI to >> do so now as their build will break when this option is removed. >> > > It turns out that on DreamPlug (armv5te) the unit won't boot all the way > to multiuser mode with EABI, building with gcc or clang. I first > discovered this a few days ago when I realized I was still building with > OABI on dreamplug and tried to switch. I tried going back to a revision > in late July but that didn't make any difference. The before getting > any further with bisecting I heard from Ilya Bakulin on irc that the > problems I'm seeing (hanging in rc.d/initrandom and rc.d/var) go back to > at least April. > > The rc.d/initrandom problem seems to be while running the 'df' command > to "generate entropy." In rc.d/var the problem is while running newfs > on /dev/md0, and I can more readily confirm that -- if I use ^C to get > past the hangs in rc.d processing it'll limp its way to multiuser mode, > and if you manually try to "newfs /dev/md0" it definitely hangs the same > way. When it's hung in that state, a ^T gives no info, but a ^C does > break out of the hang. I've been unable to get any more info about > how/why it's hung. > > I can understand a desire to not let any 10.0 release get into the wild > with OABI support, but I'm not sure that removing the ability to even > try OABI to see if it fixes a problem is a good idea. EABI just doesn't > have enough testing to declare that it's solid (because clearly it's not > yet solid). Can we declare that OABI isn't supported without removing > the ability to fall back to it for testing purposes? I wouldn't mind if > enabling it requires something like WITH_UNSUPPORTED_OABI_FOR_TESTING. > > -- Ian My Sheevaplug does not finish booting anymore either. ## Starting application at 0x00900000 ... 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-CURRENT #12: Thu Aug 29 15:14:50 CEST 2013 root@mailjail.klop.ws:/usr/obj/arm.arm/usr/src/sys/SHEEVAPLUG arm FreeBSD clang version 3.3 (tags/RELEASE_33/final 183502) 20130610 CPU: Feroceon 88FR131 rev 1 (Marvell core) Little-endian DC enabled IC enabled WA disabled DC streaming enabled BTB disabled L2 enabled L2 prefetch enabled WB enabled EABT branch prediction enabled 16KB/32B 4-way instruction cache 16KB/32B 4-way write-back-locking-C data cache real memory = 536870912 (512 MB) avail memory = 518934528 (494 MB) SOC: Marvell 88F6281 rev A0, TClock 200MHz Instruction cache prefetch enabled, data cache prefetch enabled 256KB 4-way set-associative write-through unified L2 cache random device not loaded; using insecure entropy random: initialized localbus0: on fdtbus0 nand0: mem 0xf9300000-0xf93fffff on localbus0 nandbus0: on nand0 lnand0: on nandbus0 lnand0: Found BBT table for chip simplebus0: on fdtbus0 ic0: mem 0xf1020200-0xf102023b on simplebus0 timer0: mem 0xf1020300-0xf102032f irq 1 on simplebus0 Event timer "CPUTimer0" frequency 200000000 Hz quality 1000 Timecounter "CPUTimer1" frequency 200000000 Hz quality 1000 gpio0: mem 0xf1010100-0xf101011f irq 35,36,37,38,39,40,41 on simplebus0 rtc0: mem 0xf1010300-0xf1010307 on simplebus0 mge0: mem 0xf1072000-0xf1073fff irq 12,13,14,11,46 on simplebus0 mge0: Ethernet address: 00:50:43:01:6f:12 miibus0: on mge0 e1000phy0: PHY 0 on miibus0 e1000phy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto uart0: <16550 or compatible> mem 0xf1012000-0xf101201f irq 33 on simplebus0 uart0: console (1066,n,8,1) uart1: <16550 or compatible> mem 0xf1012100-0xf101211f irq 34 on simplebus0 cesa0: mem 0xf1030000-0xf103ffff irq 22 on simplebus0 ehci0: mem 0xf1050000-0xf1050fff irq 48,19 on simplebus0 usbus0: EHCI version 1.0 usbus0: set host controller mode usbus0 on ehci0 cryptosoft0: Timecounters tick every 1.000 msec ipfw2 initialized, divert loadable, nat loadable, default to accept, logging disabled usbus0: 480Mbps High Speed USB v2.0 ugen0.1: at usbus0 uhub0: on usbus0 Root mount waiting for: usbus0 uhub0: 1 port with 1 removable, self powered Root mount waiting for: usbus0 ugen0.2: at usbus0 umass0: on usbus0 umass0: SCSI over Bulk-Only; quirks = 0x4000 umass0:0:0:-1: Attached to scbus0 Trying to mount root from ufs:/dev/da0s2 []... mountroot: waiting for device /dev/da0s2 ... da0 at umass-sim0 bus 0 scbus0 target 0 lun 0 da0: Removable Direct Access SCSI-0 device da0: 40.000MB/s transfers da0: 3894MB (7975296 512 byte sectors: 255H 63S/T 496C) da0: quirks=0x2 Setting hostuuid: 64f53bc5-bfde-11d3-902f-005043016d4c. Setting hostid: 0x2afd1481. No suitable dump device was found. Entropy harvesting: interrupts ethernet point_to_point ^C or ^T don't do anything. But when I remove the usb-stick it prints info about it. ugen0.2: at usbus0 (disconnected) umass0: at uhub0, port 1, addr 2 (disconnected) (da0:umass-sim0:0:0:0): lost device - 0 outstanding, 3 refs (da0:umass-sim0:0:0:0): removing device entry If I can help to resolve this, than I can spend some time on it. I can program, but am not aware of the kernel internals. I can break into the debugger. Ronald. From owner-freebsd-arm@FreeBSD.ORG Thu Aug 29 14:23: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 853016D9 for ; Thu, 29 Aug 2013 14:23:21 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-qa0-x22c.google.com (mail-qa0-x22c.google.com [IPv6:2607:f8b0:400d:c00::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 43B762B9F for ; Thu, 29 Aug 2013 14:23:21 +0000 (UTC) Received: by mail-qa0-f44.google.com with SMTP id w8so3021465qac.17 for ; Thu, 29 Aug 2013 07:23:20 -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=cIXCw3EP0zIiI4zTSd8legtKR0lb8qys9cpdYaj9w64=; b=QoxPPgEmNz/JO5ON9SCuoy33fzJR/Ux26aNtzz09myy9nvN9OxnPx6U/cu2/AamfhM aTN3mmxBe8vSe2R+b6UKZrxHeq75M8NeSQQXsjWbQBwCYBHLHVoYo1usG/mzFpHVdy8S ewOse+YXbKgpYB5RJwJREC28u1H4mR+Qcj/HQ/E2fOvfYdMoNeFYuhIbxpVRIPI35v2t R4SCk+pvfiLKmaBhJzQWiDQz27ZEGKkoIYtXg3KhfifAn84PU3dIyDRR+Yc6hWaGt4Xc cTg3isYiDM3bviYJ+u0rny9PalluCQmyE/U9Z6DvLOlJX64Uf12HZfYB/x/tzKxy228p CYNw== MIME-Version: 1.0 X-Received: by 10.229.214.200 with SMTP id hb8mr4306163qcb.1.1377786200322; Thu, 29 Aug 2013 07:23:20 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.224.128.70 with HTTP; Thu, 29 Aug 2013 07:23:20 -0700 (PDT) In-Reply-To: References: <20130820091527.42127170@bender.Home> <1377271598.1111.78.camel@revolution.hippie.lan> Date: Thu, 29 Aug 2013 07:23:20 -0700 X-Google-Sender-Auth: 1SOsVr_EiveAbDbwibJaEa-wtUU Message-ID: Subject: Re: Reminder: Removal of WITHOUT_ARM_EABI From: Adrian Chadd To: Ronald Klop 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, 29 Aug 2013 14:23:21 -0000 Hm, which commit broke this? Did someone commit something to the random number framework that is hanging the kernel early because there's not enough entropy? -adrian On 29 August 2013 07:15, Ronald Klop wrote: > On Fri, 23 Aug 2013 17:26:38 +0200, Ian Lepore wrote: > > On Tue, 2013-08-20 at 09:15 +0100, Andrew Turner wrote: >> >>> I am planning on removing WITHOUT_ARM_EABI before 10.0 is released. As >>> this is planned on happening soon it this change is likely to happen >>> within the next two weeks, after a short heads up. >>> >>> This is a reminder for people who have not yet moved to the ARM EABI to >>> do so now as their build will break when this option is removed. >>> >>> >> It turns out that on DreamPlug (armv5te) the unit won't boot all the way >> to multiuser mode with EABI, building with gcc or clang. I first >> discovered this a few days ago when I realized I was still building with >> OABI on dreamplug and tried to switch. I tried going back to a revision >> in late July but that didn't make any difference. The before getting >> any further with bisecting I heard from Ilya Bakulin on irc that the >> problems I'm seeing (hanging in rc.d/initrandom and rc.d/var) go back to >> at least April. >> >> The rc.d/initrandom problem seems to be while running the 'df' command >> to "generate entropy." In rc.d/var the problem is while running newfs >> on /dev/md0, and I can more readily confirm that -- if I use ^C to get >> past the hangs in rc.d processing it'll limp its way to multiuser mode, >> and if you manually try to "newfs /dev/md0" it definitely hangs the same >> way. When it's hung in that state, a ^T gives no info, but a ^C does >> break out of the hang. I've been unable to get any more info about >> how/why it's hung. >> >> I can understand a desire to not let any 10.0 release get into the wild >> with OABI support, but I'm not sure that removing the ability to even >> try OABI to see if it fixes a problem is a good idea. EABI just doesn't >> have enough testing to declare that it's solid (because clearly it's not >> yet solid). Can we declare that OABI isn't supported without removing >> the ability to fall back to it for testing purposes? I wouldn't mind if >> enabling it requires something like WITH_UNSUPPORTED_OABI_FOR_**TESTING. >> >> -- Ian >> > > My Sheevaplug does not finish booting anymore either. > > ## Starting application at 0x00900000 ... > 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-CURRENT #12: Thu Aug 29 15:14:50 CEST 2013 > root@mailjail.klop.ws:/usr/**obj/arm.arm/usr/src/sys/**SHEEVAPLUG arm > FreeBSD clang version 3.3 (tags/RELEASE_33/final 183502) 20130610 > CPU: Feroceon 88FR131 rev 1 (Marvell core) > Little-endian DC enabled IC enabled WA disabled DC streaming enabled > BTB disabled L2 enabled L2 prefetch enabled > WB enabled EABT branch prediction enabled > 16KB/32B 4-way instruction cache > 16KB/32B 4-way write-back-locking-C data cache > real memory = 536870912 (512 MB) > avail memory = 518934528 (494 MB) > SOC: Marvell 88F6281 rev A0, TClock 200MHz > Instruction cache prefetch enabled, data cache prefetch enabled > 256KB 4-way set-associative write-through unified L2 cache > random device not loaded; using insecure entropy > random: initialized > localbus0: on fdtbus0 > nand0: mem 0xf9300000-0xf93fffff on localbus0 > nandbus0: on nand0 > lnand0: on nandbus0 > lnand0: Found BBT table for chip > simplebus0: on fdtbus0 > ic0: mem 0xf1020200-0xf102023b > on simplebus0 > timer0: mem 0xf1020300-0xf102032f irq 1 on simplebus0 > Event timer "CPUTimer0" frequency 200000000 Hz quality 1000 > Timecounter "CPUTimer1" frequency 200000000 Hz quality 1000 > gpio0: mem 0xf1010100-0xf101011f irq > 35,36,37,38,39,40,41 on simplebus0 > rtc0: mem 0xf1010300-0xf1010307 on simplebus0 > mge0: mem 0xf1072000-0xf1073fff irq > 12,13,14,11,46 on simplebus0 > mge0: Ethernet address: 00:50:43:01:6f:12 > miibus0: on mge0 > e1000phy0: PHY 0 on miibus0 > e1000phy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, > 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto > uart0: <16550 or compatible> mem 0xf1012000-0xf101201f irq 33 on simplebus0 > uart0: console (1066,n,8,1) > uart1: <16550 or compatible> mem 0xf1012100-0xf101211f irq 34 on simplebus0 > cesa0: mem > 0xf1030000-0xf103ffff irq 22 on simplebus0 > ehci0: mem 0xf1050000-0xf1050fff > irq 48,19 on simplebus0 > usbus0: EHCI version 1.0 > usbus0: set host controller mode > usbus0 on ehci0 > cryptosoft0: > Timecounters tick every 1.000 msec > ipfw2 initialized, divert loadable, nat loadable, default to accept, > logging disabled > usbus0: 480Mbps High Speed USB v2.0 > ugen0.1: at usbus0 > uhub0: on usbus0 > Root mount waiting for: usbus0 > uhub0: 1 port with 1 removable, self powered > Root mount waiting for: usbus0 > ugen0.2: at usbus0 > umass0: on > usbus0 > umass0: SCSI over Bulk-Only; quirks = 0x4000 > umass0:0:0:-1: Attached to scbus0 > Trying to mount root from ufs:/dev/da0s2 []... > mountroot: waiting for device /dev/da0s2 ... > da0 at umass-sim0 bus 0 scbus0 target 0 lun 0 > da0: Removable Direct Access SCSI-0 device > da0: 40.000MB/s transfers > da0: 3894MB (7975296 512 byte sectors: 255H 63S/T 496C) > da0: quirks=0x2 > Setting hostuuid: 64f53bc5-bfde-11d3-902f-**005043016d4c. > Setting hostid: 0x2afd1481. > No suitable dump device was found. > Entropy harvesting: interrupts ethernet point_to_point > > ^C or ^T don't do anything. But when I remove the usb-stick it prints info > about it. > > ugen0.2: at usbus0 (disconnected) > umass0: at uhub0, port 1, addr 2 (disconnected) > (da0:umass-sim0:0:0:0): lost device - 0 outstanding, 3 refs > (da0:umass-sim0:0:0:0): removing device entry > > If I can help to resolve this, than I can spend some time on it. I can > program, but am not aware of the kernel internals. > I can break into the debugger. > > Ronald. > > ______________________________**_________________ > 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 Aug 29 14:42: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 55DD9E97; Thu, 29 Aug 2013 14:42: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 166DF2CBE; Thu, 29 Aug 2013 14:42:11 +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 1VF3QB-0006VX-Og; Thu, 29 Aug 2013 14:42: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 r7TEfxMT055648; Thu, 29 Aug 2013 08:41: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: U2FsdGVkX18QpOFwXicf52yTe5ZzKoLW Subject: Re: Reminder: Removal of WITHOUT_ARM_EABI From: Ian Lepore To: Adrian Chadd In-Reply-To: References: <20130820091527.42127170@bender.Home> <1377271598.1111.78.camel@revolution.hippie.lan> Content-Type: text/plain; charset="us-ascii" Date: Thu, 29 Aug 2013 08:41:59 -0600 Message-ID: <1377787319.1111.277.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: Thu, 29 Aug 2013 14:42:12 -0000 On Thu, 2013-08-29 at 07:23 -0700, Adrian Chadd wrote: > Hm, which commit broke this? > > Did someone commit something to the random number framework that is hanging > the kernel early because there's not enough entropy? > As mentioned in the text below (which of course will get trimmed now by sensible mail clients because you top-posted in a bottom-posted thread), it has been broken since at least April. This problem is somewhat resistant to simple debugging -- the kernel isn't hung overall, but some userland processes become hung while waiting for something in the kernel. It's not a deadlock that witness can detect, it seems to be something more like waiting for IO to complete and it never does. Running newfs on a /dev/md# will hang for sure (but you can ^C out of it). While it's in this state, you cannot launch top or ps or any of the usual tools for figuring out what the system is doing -- the tools also hang, and they do NOT respond to a ^C when hung (but will exit with a kill -9 from another shell). -- Ian > > On 29 August 2013 07:15, Ronald Klop wrote: > > > On Fri, 23 Aug 2013 17:26:38 +0200, Ian Lepore wrote: > > > > On Tue, 2013-08-20 at 09:15 +0100, Andrew Turner wrote: > >> > >>> I am planning on removing WITHOUT_ARM_EABI before 10.0 is released. As > >>> this is planned on happening soon it this change is likely to happen > >>> within the next two weeks, after a short heads up. > >>> > >>> This is a reminder for people who have not yet moved to the ARM EABI to > >>> do so now as their build will break when this option is removed. > >>> > >>> > >> It turns out that on DreamPlug (armv5te) the unit won't boot all the way > >> to multiuser mode with EABI, building with gcc or clang. I first > >> discovered this a few days ago when I realized I was still building with > >> OABI on dreamplug and tried to switch. I tried going back to a revision > >> in late July but that didn't make any difference. The before getting > >> any further with bisecting I heard from Ilya Bakulin on irc that the > >> problems I'm seeing (hanging in rc.d/initrandom and rc.d/var) go back to > >> at least April. > >> > >> The rc.d/initrandom problem seems to be while running the 'df' command > >> to "generate entropy." In rc.d/var the problem is while running newfs > >> on /dev/md0, and I can more readily confirm that -- if I use ^C to get > >> past the hangs in rc.d processing it'll limp its way to multiuser mode, > >> and if you manually try to "newfs /dev/md0" it definitely hangs the same > >> way. When it's hung in that state, a ^T gives no info, but a ^C does > >> break out of the hang. I've been unable to get any more info about > >> how/why it's hung. > >> > >> I can understand a desire to not let any 10.0 release get into the wild > >> with OABI support, but I'm not sure that removing the ability to even > >> try OABI to see if it fixes a problem is a good idea. EABI just doesn't > >> have enough testing to declare that it's solid (because clearly it's not > >> yet solid). Can we declare that OABI isn't supported without removing > >> the ability to fall back to it for testing purposes? I wouldn't mind if > >> enabling it requires something like WITH_UNSUPPORTED_OABI_FOR_**TESTING. > >> > >> -- Ian > >> > > > > My Sheevaplug does not finish booting anymore either. > > > > ## Starting application at 0x00900000 ... > > 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-CURRENT #12: Thu Aug 29 15:14:50 CEST 2013 > > root@mailjail.klop.ws:/usr/**obj/arm.arm/usr/src/sys/**SHEEVAPLUG arm > > FreeBSD clang version 3.3 (tags/RELEASE_33/final 183502) 20130610 > > CPU: Feroceon 88FR131 rev 1 (Marvell core) > > Little-endian DC enabled IC enabled WA disabled DC streaming enabled > > BTB disabled L2 enabled L2 prefetch enabled > > WB enabled EABT branch prediction enabled > > 16KB/32B 4-way instruction cache > > 16KB/32B 4-way write-back-locking-C data cache > > real memory = 536870912 (512 MB) > > avail memory = 518934528 (494 MB) > > SOC: Marvell 88F6281 rev A0, TClock 200MHz > > Instruction cache prefetch enabled, data cache prefetch enabled > > 256KB 4-way set-associative write-through unified L2 cache > > random device not loaded; using insecure entropy > > random: initialized > > localbus0: on fdtbus0 > > nand0: mem 0xf9300000-0xf93fffff on localbus0 > > nandbus0: on nand0 > > lnand0: on nandbus0 > > lnand0: Found BBT table for chip > > simplebus0: on fdtbus0 > > ic0: mem 0xf1020200-0xf102023b > > on simplebus0 > > timer0: mem 0xf1020300-0xf102032f irq 1 on simplebus0 > > Event timer "CPUTimer0" frequency 200000000 Hz quality 1000 > > Timecounter "CPUTimer1" frequency 200000000 Hz quality 1000 > > gpio0: mem 0xf1010100-0xf101011f irq > > 35,36,37,38,39,40,41 on simplebus0 > > rtc0: mem 0xf1010300-0xf1010307 on simplebus0 > > mge0: mem 0xf1072000-0xf1073fff irq > > 12,13,14,11,46 on simplebus0 > > mge0: Ethernet address: 00:50:43:01:6f:12 > > miibus0: on mge0 > > e1000phy0: PHY 0 on miibus0 > > e1000phy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, > > 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto > > uart0: <16550 or compatible> mem 0xf1012000-0xf101201f irq 33 on simplebus0 > > uart0: console (1066,n,8,1) > > uart1: <16550 or compatible> mem 0xf1012100-0xf101211f irq 34 on simplebus0 > > cesa0: mem > > 0xf1030000-0xf103ffff irq 22 on simplebus0 > > ehci0: mem 0xf1050000-0xf1050fff > > irq 48,19 on simplebus0 > > usbus0: EHCI version 1.0 > > usbus0: set host controller mode > > usbus0 on ehci0 > > cryptosoft0: > > Timecounters tick every 1.000 msec > > ipfw2 initialized, divert loadable, nat loadable, default to accept, > > logging disabled > > usbus0: 480Mbps High Speed USB v2.0 > > ugen0.1: at usbus0 > > uhub0: on usbus0 > > Root mount waiting for: usbus0 > > uhub0: 1 port with 1 removable, self powered > > Root mount waiting for: usbus0 > > ugen0.2: at usbus0 > > umass0: on > > usbus0 > > umass0: SCSI over Bulk-Only; quirks = 0x4000 > > umass0:0:0:-1: Attached to scbus0 > > Trying to mount root from ufs:/dev/da0s2 []... > > mountroot: waiting for device /dev/da0s2 ... > > da0 at umass-sim0 bus 0 scbus0 target 0 lun 0 > > da0: Removable Direct Access SCSI-0 device > > da0: 40.000MB/s transfers > > da0: 3894MB (7975296 512 byte sectors: 255H 63S/T 496C) > > da0: quirks=0x2 > > Setting hostuuid: 64f53bc5-bfde-11d3-902f-**005043016d4c. > > Setting hostid: 0x2afd1481. > > No suitable dump device was found. > > Entropy harvesting: interrupts ethernet point_to_point > > > > ^C or ^T don't do anything. But when I remove the usb-stick it prints info > > about it. > > > > ugen0.2: at usbus0 (disconnected) > > umass0: at uhub0, port 1, addr 2 (disconnected) > > (da0:umass-sim0:0:0:0): lost device - 0 outstanding, 3 refs > > (da0:umass-sim0:0:0:0): removing device entry > > > > If I can help to resolve this, than I can spend some time on it. I can > > program, but am not aware of the kernel internals. > > I can break into the debugger. > > > > Ronald. > > > > ______________________________**_________________ > > 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 Thu Aug 29 14:43: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 CD310F25 for ; Thu, 29 Aug 2013 14:43:04 +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 2FD4A2CCC for ; Thu, 29 Aug 2013 14:43:03 +0000 (UTC) Received: from cpsps-ews12.kpnxchange.com ([10.94.84.179]) by cpsmtpb-ews07.kpnxchange.com with Microsoft SMTPSVC(7.5.7601.17514); Thu, 29 Aug 2013 16:41:56 +0200 Received: from CPSMTPM-TLF103.kpnxchange.com ([195.121.3.6]) by cpsps-ews12.kpnxchange.com with Microsoft SMTPSVC(7.5.7601.17514); Thu, 29 Aug 2013 16:41:56 +0200 Received: from sjakie.klop.ws ([212.182.167.131]) by CPSMTPM-TLF103.kpnxchange.com with Microsoft SMTPSVC(7.5.7601.17514); Thu, 29 Aug 2013 16:41:56 +0200 Received: from 212-182-167-131.ip.telfort.nl (localhost [127.0.0.1]) by sjakie.klop.ws (Postfix) with ESMTP id 2547FC3F1 for ; Thu, 29 Aug 2013 16:41:56 +0200 (CEST) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes To: freebsd-arm@freebsd.org Subject: Re: Reminder: Removal of WITHOUT_ARM_EABI References: <20130820091527.42127170@bender.Home> <1377271598.1111.78.camel@revolution.hippie.lan> Date: Thu, 29 Aug 2013 16:41:55 +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: 29 Aug 2013 14:41:56.0280 (UTC) FILETIME=[E8DF8B80:01CEA4C5] 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, 29 Aug 2013 14:43:05 -0000 On Thu, 29 Aug 2013 16:23:20 +0200, Adrian Chadd wrote: > Hm, which commit broke this? > > Did someone commit something to the random number framework that is > hanging > the kernel early because there's not enough entropy? > > > > -adrian As Ian pointed out, it hangs on 'df'. I added 'set -x' to initrandom_start() in /etc/rc.d/initrandom which gives this output. + sysctl kern.random + soft_random_generator='kern.random.adaptors: yarrow kern.random.yarrow.gengateinterval: 10 kern.random.yarrow.bins: 10 kern.random.yarrow.fastthresh: 192 kern.random.yarrow.slowthresh: 256 kern.random.yarrow.slowoverthresh: 2 kern.random.sys.seeded: 1 kern.random.sys.harvest.ethernet: 1 kern.random.sys.harvest.point_to_point: 1 kern.random.sys.harvest.interrupt: 1 kern.random.sys.harvest.swi: 0' + echo -n 'Entropy harvesting:' Entropy harvesting:+ [ ! -z 'kern.random.adaptors: yarrow kern.random.yarrow.gengateinterval: 10 kern.random.yarrow.bins: 10 kern.random.yarrow.fastthresh: 192 kern.random.yarrow.slowthresh: 256 kern.random.yarrow.slowoverthresh: 2 kern.random.sys.seeded: 1 kern.random.sys.harvest.ethernet: 1 kern.random.sys.harvest.point_to_point: 1 kern.random.sys.harvest.interrupt: 1 kern.random.sys.harvest.swi: 0' ] + [ -w /dev/random ] + checkyesno harvest_interrupt + eval '_value=$harvest_interrupt' + _value=YES + debug 'checkyesno: harvest_interrupt is set to YES.' + return 0 + /sbin/sysctl kern.random.sys.harvest.interrupt=1 + echo -n ' interrupts' interrupts+ checkyesno harvest_ethernet + eval '_value=$harvest_ethernet' + _value=YES + debug 'checkyesno: harvest_ethernet is set to YES.' + return 0 + /sbin/sysctl kern.random.sys.harvest.ethernet=1 + echo -n ' ethernet' ethernet+ checkyesno harvest_p_to_p + eval '_value=$harvest_p_to_p' + _value=YES + debug 'checkyesno: harvest_p_to_p is set to YES.' + return 0 + /sbin/sysctl kern.random.sys.harvest.point_to_point=1 + echo -n ' point_to_point' point_to_point+ [ -w /dev/random ] + feed_dev_random /entropy + [ -f /entropy -a -r /entropy -a -s /entropy ] + cat /entropy + dd of=/dev/random bs=8k + better_than_nothing + dd of=/dev/random bs=8k + kenv + dmesg + df -ib db> ps pid ppid pgrp uid state wmesg wchan cmd 47 43 17 0 R+ CPU 0 df 44 36 17 0 S+ piperd 0xc3e9c720 dd 43 36 17 0 S+ wait 0xc3e3a960 sh 36 17 17 0 S+ wait 0xc3e3b320 sh 17 1 17 0 Ss+ wait 0xc3e3b640 sh 16 0 0 0 DL - 0xc0cca3b0 [schedcpu] 15 0 0 0 DL syncer 0xc0cdb7cc [syncer] 9 0 0 0 DL vlruwt 0xc3e40000 [vnlru] 8 0 0 0 DL psleep 0xc0cdb550 [bufdaemon] 7 0 0 0 DL pollid 0xc0cc9b68 [idlepoll] 6 0 0 0 RL [pagezero] 5 0 0 0 DL psleep 0xc0cea7c4 [pagedaemon] 4 0 0 0 DL ccb_scan 0xc0cbdd10 [xpt_thrd] 14 0 0 0 DL (threaded) [usb] 100028 D - 0xc3d1cd34 [usbus0] 100027 D - 0xc3d1cd04 [usbus0] 100026 D - 0xc3d1ccd4 [usbus0] 100025 D - 0xc3d1cca4 [usbus0] 13 0 0 0 DL - 0xc0cc0a44 [yarrow] 3 0 0 0 DL crypto_r 0xc0cde6c0 [crypto returns] 2 0 0 0 DL crypto_w 0xc0cde6b0 [crypto] 12 0 0 0 DL (threaded) [geom] 100008 D - 0xc0ce81a8 [g_down] 100007 D - 0xc0ce81a4 [g_up] 100006 D - 0xc0ce81a0 [g_event] 11 0 0 0 WL (threaded) [intr] 100024 I [intr19: ehci0] 100023 I [intr22: cesa0] 100022 I [swi0: uart uart] 100021 I [intr13: mge0] 100020 I [intr12: mge0] 100018 I [swi5: fast taskq] 100016 I [swi6: Giant taskq] 100015 I [swi6: task queue] 100012 I [swi2: cambio] 100005 I [swi3: vm] 100004 I [swi1: netisr 0] 100003 I [swi4: clock] 10 0 0 0 RL [idle] 1 0 1 0 SLs wait 0xc3466640 [init] 0 0 0 0 DLs (threaded) [kernel] 100019 D - 0xc3453c80 [nand taskq] 100017 D - 0xc3454480 [thread taskq] 100014 D - 0xc3454d80 [ffs_trim taskq] 100013 D - 0xc3454e00 [kqueue taskq] 100000 D swapin 0xc0ce81c8 [swapper] Regards, Ronald. > > > > On 29 August 2013 07:15, Ronald Klop wrote: > >> On Fri, 23 Aug 2013 17:26:38 +0200, Ian Lepore wrote: >> >> On Tue, 2013-08-20 at 09:15 +0100, Andrew Turner wrote: >>> >>>> I am planning on removing WITHOUT_ARM_EABI before 10.0 is released. As >>>> this is planned on happening soon it this change is likely to happen >>>> within the next two weeks, after a short heads up. >>>> >>>> This is a reminder for people who have not yet moved to the ARM EABI >>>> to >>>> do so now as their build will break when this option is removed. >>>> >>>> >>> It turns out that on DreamPlug (armv5te) the unit won't boot all the >>> way >>> to multiuser mode with EABI, building with gcc or clang. I first >>> discovered this a few days ago when I realized I was still building >>> with >>> OABI on dreamplug and tried to switch. I tried going back to a >>> revision >>> in late July but that didn't make any difference. The before getting >>> any further with bisecting I heard from Ilya Bakulin on irc that the >>> problems I'm seeing (hanging in rc.d/initrandom and rc.d/var) go back >>> to >>> at least April. >>> >>> The rc.d/initrandom problem seems to be while running the 'df' command >>> to "generate entropy." In rc.d/var the problem is while running newfs >>> on /dev/md0, and I can more readily confirm that -- if I use ^C to get >>> past the hangs in rc.d processing it'll limp its way to multiuser mode, >>> and if you manually try to "newfs /dev/md0" it definitely hangs the >>> same >>> way. When it's hung in that state, a ^T gives no info, but a ^C does >>> break out of the hang. I've been unable to get any more info about >>> how/why it's hung. >>> >>> I can understand a desire to not let any 10.0 release get into the wild >>> with OABI support, but I'm not sure that removing the ability to even >>> try OABI to see if it fixes a problem is a good idea. EABI just >>> doesn't >>> have enough testing to declare that it's solid (because clearly it's >>> not >>> yet solid). Can we declare that OABI isn't supported without removing >>> the ability to fall back to it for testing purposes? I wouldn't mind >>> if >>> enabling it requires something like >>> WITH_UNSUPPORTED_OABI_FOR_**TESTING. >>> >>> -- Ian >>> >> >> My Sheevaplug does not finish booting anymore either. >> >> ## Starting application at 0x00900000 ... >> 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-CURRENT #12: Thu Aug 29 15:14:50 CEST 2013 >> root@mailjail.klop.ws:/usr/**obj/arm.arm/usr/src/sys/**SHEEVAPLUG >> arm >> FreeBSD clang version 3.3 (tags/RELEASE_33/final 183502) 20130610 >> CPU: Feroceon 88FR131 rev 1 (Marvell core) >> Little-endian DC enabled IC enabled WA disabled DC streaming enabled >> BTB disabled L2 enabled L2 prefetch enabled >> WB enabled EABT branch prediction enabled >> 16KB/32B 4-way instruction cache >> 16KB/32B 4-way write-back-locking-C data cache >> real memory = 536870912 (512 MB) >> avail memory = 518934528 (494 MB) >> SOC: Marvell 88F6281 rev A0, TClock 200MHz >> Instruction cache prefetch enabled, data cache prefetch enabled >> 256KB 4-way set-associative write-through unified L2 cache >> random device not loaded; using insecure entropy >> random: initialized >> localbus0: on fdtbus0 >> nand0: mem 0xf9300000-0xf93fffff on localbus0 >> nandbus0: on nand0 >> lnand0: on nandbus0 >> lnand0: Found BBT table for chip >> simplebus0: on fdtbus0 >> ic0: mem 0xf1020200-0xf102023b >> on simplebus0 >> timer0: mem 0xf1020300-0xf102032f irq 1 on >> simplebus0 >> Event timer "CPUTimer0" frequency 200000000 Hz quality 1000 >> Timecounter "CPUTimer1" frequency 200000000 Hz quality 1000 >> gpio0: mem 0xf1010100-0xf101011f >> irq >> 35,36,37,38,39,40,41 on simplebus0 >> rtc0: mem 0xf1010300-0xf1010307 on simplebus0 >> mge0: mem 0xf1072000-0xf1073fff >> irq >> 12,13,14,11,46 on simplebus0 >> mge0: Ethernet address: 00:50:43:01:6f:12 >> miibus0: on mge0 >> e1000phy0: PHY 0 on miibus0 >> e1000phy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, >> 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto >> uart0: <16550 or compatible> mem 0xf1012000-0xf101201f irq 33 on >> simplebus0 >> uart0: console (1066,n,8,1) >> uart1: <16550 or compatible> mem 0xf1012100-0xf101211f irq 34 on >> simplebus0 >> cesa0: mem >> 0xf1030000-0xf103ffff irq 22 on simplebus0 >> ehci0: mem 0xf1050000-0xf1050fff >> irq 48,19 on simplebus0 >> usbus0: EHCI version 1.0 >> usbus0: set host controller mode >> usbus0 on ehci0 >> cryptosoft0: >> Timecounters tick every 1.000 msec >> ipfw2 initialized, divert loadable, nat loadable, default to accept, >> logging disabled >> usbus0: 480Mbps High Speed USB v2.0 >> ugen0.1: at usbus0 >> uhub0: on >> usbus0 >> Root mount waiting for: usbus0 >> uhub0: 1 port with 1 removable, self powered >> Root mount waiting for: usbus0 >> ugen0.2: at usbus0 >> umass0: on >> usbus0 >> umass0: SCSI over Bulk-Only; quirks = 0x4000 >> umass0:0:0:-1: Attached to scbus0 >> Trying to mount root from ufs:/dev/da0s2 []... >> mountroot: waiting for device /dev/da0s2 ... >> da0 at umass-sim0 bus 0 scbus0 target 0 lun 0 >> da0: Removable Direct Access SCSI-0 >> device >> da0: 40.000MB/s transfers >> da0: 3894MB (7975296 512 byte sectors: 255H 63S/T 496C) >> da0: quirks=0x2 >> Setting hostuuid: 64f53bc5-bfde-11d3-902f-**005043016d4c. >> Setting hostid: 0x2afd1481. >> No suitable dump device was found. >> Entropy harvesting: interrupts ethernet point_to_point >> >> ^C or ^T don't do anything. But when I remove the usb-stick it prints >> info >> about it. >> >> ugen0.2: at usbus0 (disconnected) >> umass0: at uhub0, port 1, addr 2 (disconnected) >> (da0:umass-sim0:0:0:0): lost device - 0 outstanding, 3 refs >> (da0:umass-sim0:0:0:0): removing device entry >> >> If I can help to resolve this, than I can spend some time on it. I can >> program, but am not aware of the kernel internals. >> I can break into the debugger. >> >> Ronald. >> >> ______________________________**_________________ >> 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 Thu Aug 29 15:03:14 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id AC074F1A for ; Thu, 29 Aug 2013 15:03:14 +0000 (UTC) (envelope-from 01aurelien@gmail.com) Received: from mail-ea0-x234.google.com (mail-ea0-x234.google.com [IPv6:2a00:1450:4013:c01::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 3E52F2E8E for ; Thu, 29 Aug 2013 15:03:14 +0000 (UTC) Received: by mail-ea0-f180.google.com with SMTP id h10so310609eaj.39 for ; Thu, 29 Aug 2013 08:03:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:subject:from:to:cc:date:in-reply-to:references :content-type:mime-version:content-transfer-encoding; bh=DcoRa6sj5NbmbOvLqGKvo7QEaWBdXhI4k2xDw+/ldPs=; b=L1bf7cE/dDJzqU8ZSO3DREu8aIPbs/m/YDxs+UrAA5C7c1UUBiDR/t02XiF7U+Q+QY 7isdZQJMFpHZ3M8h1evGiTyzjySCJ7Cr4d1k6mOsnVO9Jg2jweInErOnKRZ3KkJz2YCk 1hUKZaErumxlw/Nmuw4PpuWvBTxMSMg1+MWr90SsFx7CvOtF/6efvf90fQeNYWv0XFPH YQEodQrl3MmOfrpLOsxoiQRzr1yGR9JPOZ/rBek+Ta6XEUSZYofLNzPHUoVDWEW/Qe3A i9DSK4BRwIwv3318JgQ5nsT37I0K4vEP+FW6OHu57cC19iNEeAvrmjkmcZewSLTQuJUd QLhw== X-Received: by 10.14.88.65 with SMTP id z41mr4973390eee.38.1377788592636; Thu, 29 Aug 2013 08:03:12 -0700 (PDT) Received: from [128.141.43.169] (pb-d-128-141-43-169.cern.ch. [128.141.43.169]) by mx.google.com with ESMTPSA id z12sm46809559eev.6.1969.12.31.16.00.00 (version=SSLv3 cipher=RC4-SHA bits=128/128); Thu, 29 Aug 2013 08:03:12 -0700 (PDT) Message-ID: <1377788495.4692.2.camel@pandabook> Subject: Re: unbound compilation issue rpi From: Aurelien Martin <01aurelien@gmail.com> To: Paul Mather Date: Thu, 29 Aug 2013 17:01:35 +0200 In-Reply-To: References: <1377705113.23901.8.camel@pandabook> <20130828163545.GA55072@ci0.org> <1377761762.6953.7.camel@pandabook> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.4.4-3 Mime-Version: 1.0 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, 29 Aug 2013 15:03:14 -0000 Hi Paul, Thanks for your feedback ! In deed with > CC=gcc > CXX=g++ > CPP=gcpp It work like a charm ! As you can expect, I cannot reply for the compilator issue. Have a nice day Aurelien On Thu, 2013-08-29 at 08:44 -0400, Paul Mather wrote: > On Aug 29, 2013, at 3:36 AM, Aurelien Martin <01aurelien@gmail.com> wrote: > > > Hi Olivier, > > > > I did "make clean" > > http://pastebin.com/ki0c7MWf > > > > A new issue with "make install", it's seems related to gettext > > http://pastebin.com/g9K6V6EQ > > I'd say this snippet from the pastebin log is a big clue to your problem: > > ===== > checking for gcc... gcc42 > checking whether the C compiler works... no > configure: error: in `/usr/ports/devel/gettext/work/gettext-0.18.3/gettext-runtime': > configure: error: C compiler cannot create executables > ===== > > As someone else asked previously, why are you using gcc42 instead of the built-in gcc? Is the gcc42 port known to work correctly on arm? > > You might try this instead: > > CC=gcc > CXX=g++ > CPP=gcpp > > I would have said the built-in compiler has a better track record of working than any other on FreeBSD/arm, but now I'm not sure that is even true with the move to EABI. Does gcc on arm support EABI, or just clang? > > The seas are mighty rough on FreeBSD/arm nowadays... > > Cheers, > > Paul. > > > > > The "make install" advice me to sent the following attachment to > > autotools@FreeBSD.org [maintainer]. Should I ? > > > > http://pastebin.com/JpyRFshY > > > > p.s: mailing list prefer pastebin log or attachment ? > > > > Aurelien > > > > > > > > > > On Wed, 2013-08-28 at 18:35 +0200, Olivier Houchard wrote: > >> Hi Aurelien, > >> > >> On Wed, Aug 28, 2013 at 05:51:53PM +0200, Aurelien Martin wrote: > >>> Dear all, my first in mailing list :) > >>> > >>> I have a compilation failure for "unbound" (gettext seems involved) > >>> http://pastebin.com/DUmVpZ5R > >>> > >>> rpi B with: FreeBSD raspberry-pi 10.0-CURRENT FreeBSD 10.0-CURRENT #84 > >>> r252209M: Thu Jun 27 09:09:14 EDT 2013 > >>> > >>> I already ask to #freebsd channel they advice me to modify my make.conf: > >>> CC=gcc42 > >>> CXX=g++42 > >>> CPP=cpp42 > >>> > >> > >> That should probably just be gcc, g++ and cpp. > >> > >>> But almost the same errors: http://pastebin.com/jstWRMSY > >> > >> Did you run make clean ? It seems it still tries to use clang as the compiler. > >> > >> Regards, > >> > >> Olivier > > > > > > _______________________________________________ > > 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 Aug 29 16:08:48 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 B32722E5 for ; Thu, 29 Aug 2013 16:08:48 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-qe0-x229.google.com (mail-qe0-x229.google.com [IPv6:2607:f8b0:400d:c02::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 7439F2473 for ; Thu, 29 Aug 2013 16:08:48 +0000 (UTC) Received: by mail-qe0-f41.google.com with SMTP id ff1so397568qeb.0 for ; Thu, 29 Aug 2013 09:08:47 -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=w9PDsbz15pewtQIZxt/g1YuTav7/4jVBUVz9TqYgw+Q=; b=U8wlr/m5Pd9lBSyEbDlTpVldO7UFx6q2oeAF4bJaB5Jom3ZEh1RhzYofczgaW7+ouw otPiHFJLxiNxjDPru0ko/7M739oQyvzSLIOGEgzlglNDaVTySJ8I7UDkN9nFaHS1RYNZ vRVtwiiwJQXZAsOKLLTGYiVxLsvxAVwVWXxn1jLB5EQqQRc1O3nRz8NDHdBeRmjED/xI A2/KUT0zyDpnPMf2jF3D0EKWyb/1FGDdxf5fYfNzXqeF74d30NXLxaS3MvY4kTSgZhnm ApE++x3wt2zGc2uIET2z3h3i0lcJXL9JmJd44D7EdFFxVPlbeMzxBdWOq/SrQPb3SN9O /LOQ== MIME-Version: 1.0 X-Received: by 10.49.107.105 with SMTP id hb9mr4831007qeb.74.1377792527650; Thu, 29 Aug 2013 09:08:47 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.224.128.70 with HTTP; Thu, 29 Aug 2013 09:08:47 -0700 (PDT) In-Reply-To: References: <20130820091527.42127170@bender.Home> <1377271598.1111.78.camel@revolution.hippie.lan> Date: Thu, 29 Aug 2013 09:08:47 -0700 X-Google-Sender-Auth: vA2BguL1lfgdjcbKgYyYulEM_68 Message-ID: Subject: Re: Reminder: Removal of WITHOUT_ARM_EABI From: Adrian Chadd To: Ronald Klop 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, 29 Aug 2013 16:08:48 -0000 are you running with witness compiled in? can you do 'show alllocks' ? -adrian From owner-freebsd-arm@FreeBSD.ORG Thu Aug 29 16:10: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 14440498; Thu, 29 Aug 2013 16:10:51 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-qe0-x22f.google.com (mail-qe0-x22f.google.com [IPv6:2607:f8b0:400d:c02::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id B747324C9; Thu, 29 Aug 2013 16:10:50 +0000 (UTC) Received: by mail-qe0-f47.google.com with SMTP id b4so312495qen.20 for ; Thu, 29 Aug 2013 09:10:49 -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=8hW09/KlqS4a/nA4Eim5CaDT4ddsFQM2Y2prMDcQy1s=; b=NeFAaFaaxQ3rT4lnbfhviI/08e9mrilEdduGjC/2ZOCfY8BQR8bh3s6KM5bKhKXIQp 3qmybJwKtdDun7937l6StSm945C0oB4h7ne0EvTGzjOtMb32bhsToCHzvjxa2KkrnIYD TkMvsEE80wSgPqlSaiuYx+FuKgxFXnv2EQ+zxuggG6QjrnCUIBjVywOCKe5W3JuuKs4a C7zP6PWpiXdQmGi4smJnCvY/chQXK6Wfd0waUlVutk7mZLH/XjjrydFaHk+JDXjqG9m/ a1fIenwHZc/0D1nlAjU7ptgyFTMmVHrPtzhcjRTEeNe9cZG0XbKJHTGSRCrjuZqXN2NH f85w== MIME-Version: 1.0 X-Received: by 10.49.62.3 with SMTP id u3mr4900526qer.6.1377792649862; Thu, 29 Aug 2013 09:10:49 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.224.128.70 with HTTP; Thu, 29 Aug 2013 09:10:49 -0700 (PDT) In-Reply-To: <1377787319.1111.277.camel@revolution.hippie.lan> References: <20130820091527.42127170@bender.Home> <1377271598.1111.78.camel@revolution.hippie.lan> <1377787319.1111.277.camel@revolution.hippie.lan> Date: Thu, 29 Aug 2013 09:10:49 -0700 X-Google-Sender-Auth: Ezs1WHB_BpYVjCVBdfulNmGHWWI Message-ID: Subject: Re: Reminder: Removal of WITHOUT_ARM_EABI From: Adrian Chadd To: Ian Lepore Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 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: Thu, 29 Aug 2013 16:10:51 -0000 On 29 August 2013 07:41, Ian Lepore wrote: > On Thu, 2013-08-29 at 07:23 -0700, Adrian Chadd wrote: > > Hm, which commit broke this? > > > > Did someone commit something to the random number framework that is > hanging > > the kernel early because there's not enough entropy? > > > > As mentioned in the text below (which of course will get trimmed now by > sensible mail clients because you top-posted in a bottom-posted thread), > it has been broken since at least April. > .. still? Then how exactly are people commiiting to -arm? :) > This problem is somewhat resistant to simple debugging -- the kernel > isn't hung overall, but some userland processes become hung while > waiting for something in the kernel. It's not a deadlock that witness > can detect, it seems to be something more like waiting for IO to > complete and it never does. Running newfs on a /dev/md# will hang for > sure (but you can ^C out of it). While it's in this state, you cannot > launch top or ps or any of the usual tools for figuring out what the > system is doing -- the tools also hang, and they do NOT respond to a ^C > when hung (but will exit with a kill -9 from another shell). > Well, a 'show alllocks' and I think 'show allproc' or something like that should show the locks+state and the PIDs w/ their sleep channel. Hopefully they're "just" asleep waiting for some IO to occur. If it's been broken since April - does someone have a known working revision on any arm platform from April that is easy to just go kernel commit revision bisecting with? -adrian From owner-freebsd-arm@FreeBSD.ORG Thu Aug 29 16:21:26 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 00413971 for ; Thu, 29 Aug 2013 16:21:25 +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 8F5082590 for ; Thu, 29 Aug 2013 16:21:24 +0000 (UTC) Received: from cpsps-ews12.kpnxchange.com ([10.94.84.179]) by cpsmtpb-ews07.kpnxchange.com with Microsoft SMTPSVC(7.5.7601.17514); Thu, 29 Aug 2013 18:21:21 +0200 Received: from CPSMTPM-TLF103.kpnxchange.com ([195.121.3.6]) by cpsps-ews12.kpnxchange.com with Microsoft SMTPSVC(7.5.7601.17514); Thu, 29 Aug 2013 18:21:21 +0200 Received: from sjakie.klop.ws ([212.182.167.131]) by CPSMTPM-TLF103.kpnxchange.com with Microsoft SMTPSVC(7.5.7601.17514); Thu, 29 Aug 2013 18:21:20 +0200 Received: from 212-182-167-131.ip.telfort.nl (localhost [127.0.0.1]) by sjakie.klop.ws (Postfix) with ESMTP id F3F79C48C for ; Thu, 29 Aug 2013 18:21:20 +0200 (CEST) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes To: freebsd-arm@freebsd.org Subject: Re: Reminder: Removal of WITHOUT_ARM_EABI References: <20130820091527.42127170@bender.Home> <1377271598.1111.78.camel@revolution.hippie.lan> Date: Thu, 29 Aug 2013 18:21:20 +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: 29 Aug 2013 16:21:21.0059 (UTC) FILETIME=[CC289730:01CEA4D3] 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, 29 Aug 2013 16:21:26 -0000 On Thu, 29 Aug 2013 18:08:47 +0200, Adrian Chadd wrote: > are you running with witness compiled in? > > can you do 'show alllocks' ? I just compiled a new kernel with WITNESS enabled. (FYI I did not enable stuff like INVARIANTS.) makeoptions DEBUG=-g #Build kernel with gdb(1) debug symbols #options INVARIANTS #options INVARIANT_SUPPORT options WITNESS #options DEBUG_LOCKS #options DEBUG_VFS_LOCKS #options DIAGNOSTIC makeoptions WERROR="-Werror" Without WITNESS it gave this (as expected): db> show alllocks No such command With WITNESS it gives no output: db> show alllocks db> Do I miss another option in my kernel? Ronald. From owner-freebsd-arm@FreeBSD.ORG Thu Aug 29 16:42:15 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 0DA98456 for ; Thu, 29 Aug 2013 16:42:15 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-qe0-x22a.google.com (mail-qe0-x22a.google.com [IPv6:2607:f8b0:400d:c02::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id C119D270D for ; Thu, 29 Aug 2013 16:42:14 +0000 (UTC) Received: by mail-qe0-f42.google.com with SMTP id w7so339605qeb.15 for ; Thu, 29 Aug 2013 09:42:13 -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=XjgvQnwz5WYFNLWqlSsBgHGN2zRyYR+YeJkIm2b/3s4=; b=AqQ3PgHODSLe5YGafXDRxXGuSS9P669RhGg/kcGiLyqvHXAgPand02+FCZl29QR15P MRH3KU1EkO8AJ9iS69CUuX8q2+ZMDU61eYXuHMSr/qK/RhRHoLuE+g1xQjMiicDdgJqa lNAfi1rZki3KdXQ8/f0uks29EWxS/NsZSDmGkYwR+CAUWo5zqt3HcclL7dH+cdAX6D8r 7qN1SJdEG7hl1zwfLrD5DL34Zl1ogTUq8EF0VLaWrD/MMLUtua0tgXECqpVcUV3opjs/ hZOcxtssLm6bCVO7tJ00D928cDRaLHpbNNuAUKKq5/KhG80bR/fax5kjpSf86SheZG3M 8UEg== MIME-Version: 1.0 X-Received: by 10.224.97.3 with SMTP id j3mr5784460qan.87.1377794533721; Thu, 29 Aug 2013 09:42:13 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.224.128.70 with HTTP; Thu, 29 Aug 2013 09:42:13 -0700 (PDT) In-Reply-To: References: <20130820091527.42127170@bender.Home> <1377271598.1111.78.camel@revolution.hippie.lan> Date: Thu, 29 Aug 2013 09:42:13 -0700 X-Google-Sender-Auth: uA3R6t5_E4v3uPMOgbRCLvYcj9Q Message-ID: Subject: Re: Reminder: Removal of WITHOUT_ARM_EABI From: Adrian Chadd To: Ronald Klop 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, 29 Aug 2013 16:42:15 -0000 On 29 August 2013 09:21, Ronald Klop wrote: > Without WITNESS it gave this (as expected): > db> show alllocks > No such command > > With WITNESS it gives no output: > db> show alllocks > db> > > Do I miss another option in my kernel? This is once it's hung? Ok. Try 'show all procs' (or just 'ps') too. See if anything is currently sleeping on a wait channel. -adrian From owner-freebsd-arm@FreeBSD.ORG Thu Aug 29 16:42: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 2FF9B4B1 for ; Thu, 29 Aug 2013 16:42:56 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-qc0-x22d.google.com (mail-qc0-x22d.google.com [IPv6:2607:f8b0:400d:c01::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id E2ACA2714 for ; Thu, 29 Aug 2013 16:42:55 +0000 (UTC) Received: by mail-qc0-f173.google.com with SMTP id z10so367704qcx.18 for ; Thu, 29 Aug 2013 09:42:55 -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=cS3zUhMlRw/SpLZUWT3uGa4Dwwyosz87lflJ3mRePic=; b=KeRO6tSo/Llw7njKjWo1QEz3gFxitYymhytBaaciHfZbpCvNR5J8Ep3dVXLkge088o dtDfksjIRWjPQ4rottdCSG80xSWeTf4UqCsM3aUXzEdZpl1EL82JO/5Znres31KsQiqR 2esSQo6AUlbmR5++IWTRaJ1+ibptjUHdk8X8oJPV4F0VhY0GRdUSa7yHeaXV4wt+3uhC Tp+KiAZ6A83q8A0bV9swK75AUybktlQGUrOx73/6UOd44p/htf0rlmYLB1t+7jmP92o5 CBc0JwcN+gL8/3HlKLhbWDZRHz2tROLtZJQij8ZPyMyS8+7p7W7npa4D6vyG4LE7sRlp 7Lcg== MIME-Version: 1.0 X-Received: by 10.49.127.179 with SMTP id nh19mr5085851qeb.1.1377794575150; Thu, 29 Aug 2013 09:42:55 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.224.128.70 with HTTP; Thu, 29 Aug 2013 09:42:55 -0700 (PDT) In-Reply-To: References: <20130820091527.42127170@bender.Home> <1377271598.1111.78.camel@revolution.hippie.lan> Date: Thu, 29 Aug 2013 09:42:55 -0700 X-Google-Sender-Auth: fXu-jcPxXoSpq8J1XgF0XuR52U8 Message-ID: Subject: Re: Reminder: Removal of WITHOUT_ARM_EABI From: Adrian Chadd To: Ronald Klop 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, 29 Aug 2013 16:42:56 -0000 .. and 'show sleepqueue' ; 'show sleepchain' -adrian From owner-freebsd-arm@FreeBSD.ORG Thu Aug 29 16:48:45 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 0BD71785 for ; Thu, 29 Aug 2013 16:48:45 +0000 (UTC) (envelope-from ronald-freebsd8@klop.yi.org) Received: from cpsmtpb-ews08.kpnxchange.com (cpsmtpb-ews08.kpnxchange.com [213.75.39.13]) by mx1.freebsd.org (Postfix) with ESMTP id 71ADA2767 for ; Thu, 29 Aug 2013 16:48:43 +0000 (UTC) Received: from cpsps-ews06.kpnxchange.com ([10.94.84.173]) by cpsmtpb-ews08.kpnxchange.com with Microsoft SMTPSVC(7.5.7601.17514); Thu, 29 Aug 2013 18:48:43 +0200 Received: from CPSMTPM-TLF104.kpnxchange.com ([195.121.3.7]) by cpsps-ews06.kpnxchange.com with Microsoft SMTPSVC(7.5.7601.17514); Thu, 29 Aug 2013 18:48:42 +0200 Received: from sjakie.klop.ws ([212.182.167.131]) by CPSMTPM-TLF104.kpnxchange.com with Microsoft SMTPSVC(7.5.7601.17514); Thu, 29 Aug 2013 18:48:42 +0200 Received: from 212-182-167-131.ip.telfort.nl (localhost [127.0.0.1]) by sjakie.klop.ws (Postfix) with ESMTP id 675E0C4A8 for ; Thu, 29 Aug 2013 18:48:42 +0200 (CEST) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes To: freebsd-arm@freebsd.org Subject: Re: Reminder: Removal of WITHOUT_ARM_EABI References: <20130820091527.42127170@bender.Home> <1377271598.1111.78.camel@revolution.hippie.lan> Date: Thu, 29 Aug 2013 18:48:42 +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: 29 Aug 2013 16:48:42.0849 (UTC) FILETIME=[9EBDDD10:01CEA4D7] 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, 29 Aug 2013 16:48:45 -0000 On Thu, 29 Aug 2013 18:42:55 +0200, Adrian Chadd wrote: > .. and 'show sleepqueue' ; 'show sleepchain' > > > > -adrian As requested: db> show all procs pid ppid pgrp uid state wmesg wchan cmd 47 43 17 0 R+ CPU 0 df 44 36 17 0 S+ piperd 0xc4019720 dd 43 36 17 0 S+ wait 0xc3fb7960 sh 36 17 17 0 S+ wait 0xc3fb8320 sh 17 1 17 0 Ss+ wait 0xc3fb8640 sh 16 0 0 0 DL - 0xc0cd3910 [schedcpu] 15 0 0 0 DL syncer 0xc0e3e94c [syncer] 9 0 0 0 DL vlruwt 0xc3fbd000 [vnlru] 8 0 0 0 DL psleep 0xc0e3e6d0 [bufdaemon] 7 0 0 0 DL pollid 0xc0cd2fa8 [idlepoll] 6 0 0 0 DL pgzero 0xc0e42564 [pagezero] 5 0 0 0 DL psleep 0xc0e4d944 [pagedaemon] 4 0 0 0 DL ccb_scan 0xc0cc7150 [xpt_thrd] 14 0 0 0 DL (threaded) [usb] 100028 D - 0xc3e99d34 [usbus0] 100027 D - 0xc3e99d04 [usbus0] 100026 D - 0xc3e99cd4 [usbus0] 100025 D - 0xc3e99ca4 [usbus0] 3 0 0 0 DL crypto_r 0xc0e41840 [crypto returns] 2 0 0 0 DL crypto_w 0xc0e41830 [crypto] 13 0 0 0 DL - 0xc0cc9e84 [yarrow] 12 0 0 0 DL (threaded) [geom] 100008 D - 0xc0e4b328 [g_down] 100007 D - 0xc0e4b324 [g_up] 100006 D - 0xc0e4b320 [g_event] 11 0 0 0 WL (threaded) [intr] 100024 I [intr19: ehci0] 100023 I [intr22: cesa0] 100022 I [swi0: uart uart] 100021 I [intr13: mge0] 100020 I [intr12: mge0] 100018 I [swi6: Giant taskq] 100017 I [swi6: task queue] 100016 I [swi2: cambio] 100013 I [swi5: fast taskq] 100005 I [swi3: vm] 100004 I [swi1: netisr 0] 100003 I [swi4: clock] 10 0 0 0 RL [idle] 1 0 1 0 SLs wait 0xc35e3640 [init] 0 0 0 0 DLs (threaded) [kernel] 100019 D - 0xc35d0c80 [nand taskq] 100015 D - 0xc35d1580 [kqueue taskq] 100014 D - 0xc35d1d80 [ffs_trim taskq] 100012 D - 0xc35d1e80 [thread taskq] 100000 D swapin 0xc0e4b348 [swapper] db> show sleepqueue db> show sleepchain thread 100040 (pid 47, df) running on CPU 0 Regards, Ronald. From owner-freebsd-arm@FreeBSD.ORG Thu Aug 29 17:02:49 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 ACFCEF26 for ; Thu, 29 Aug 2013 17:02:49 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-qe0-x22e.google.com (mail-qe0-x22e.google.com [IPv6:2607:f8b0:400d:c02::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 6B1912878 for ; Thu, 29 Aug 2013 17:02:49 +0000 (UTC) Received: by mail-qe0-f46.google.com with SMTP id f6so355448qej.19 for ; Thu, 29 Aug 2013 10:02:48 -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=pyT4xIu3RqN/o11GmCqUvVAlRWIUlwG1ksqbJvZ70Y8=; b=ICA6SslI2Mqe/Zp4m/DSdDn7yiMa4Qe3Nx/+/mhKLEQKS9cdY+FyxGaz6uELE4Djv+ mD6yWRudWsFHjzVm2UbBYZx8sjNLGfR5I4FS0rLJUF04T02UKiEuri1VWTLu6gwdB3Np qGADpNicsTHoEQylhUb24jNukYUsGCDzdr6dtqY3B+c9yUmJ1S7qsZCcMJTSWFyZDO8q el9I5dhJqYFoP0F/4xTbbKhZxZojQitofnMF4OlbOeJNFeQDNQ0/SZHvUaGfSRcny4Ef 5XYVhZA/S0Sz2ky1m0pbgGv/+t2WJSzGYWPhWBGE5pkudELJm5h2/tzcsaEhXNka08LG HTqg== MIME-Version: 1.0 X-Received: by 10.224.66.74 with SMTP id m10mr6289288qai.12.1377795768462; Thu, 29 Aug 2013 10:02:48 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.224.128.70 with HTTP; Thu, 29 Aug 2013 10:02:48 -0700 (PDT) In-Reply-To: References: <20130820091527.42127170@bender.Home> <1377271598.1111.78.camel@revolution.hippie.lan> Date: Thu, 29 Aug 2013 10:02:48 -0700 X-Google-Sender-Auth: uADv0azSWV8caaZRTK3S63bXUW8 Message-ID: Subject: Re: Reminder: Removal of WITHOUT_ARM_EABI From: Adrian Chadd To: Ronald Klop 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, 29 Aug 2013 17:02:49 -0000 ok, next, try 'bt 47'. It should get a stack trace of the df pid. It shows its running, so.. -adrian From owner-freebsd-arm@FreeBSD.ORG Thu Aug 29 17:09:19 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 046893A2 for ; Thu, 29 Aug 2013 17:09:19 +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 6930A28D6 for ; Thu, 29 Aug 2013 17:09:17 +0000 (UTC) Received: from cpsps-ews30.kpnxchange.com ([10.94.84.196]) by cpsmtpb-ews01.kpnxchange.com with Microsoft SMTPSVC(7.5.7601.17514); Thu, 29 Aug 2013 19:08:10 +0200 Received: from CPSMTPM-TLF102.kpnxchange.com ([195.121.3.5]) by cpsps-ews30.kpnxchange.com with Microsoft SMTPSVC(7.5.7601.17514); Thu, 29 Aug 2013 19:08:10 +0200 Received: from sjakie.klop.ws ([212.182.167.131]) by CPSMTPM-TLF102.kpnxchange.com with Microsoft SMTPSVC(7.5.7601.17514); Thu, 29 Aug 2013 19:08:10 +0200 Received: from 212-182-167-131.ip.telfort.nl (localhost [127.0.0.1]) by sjakie.klop.ws (Postfix) with ESMTP id C9A81C4D5 for ; Thu, 29 Aug 2013 19:08:09 +0200 (CEST) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes To: freebsd-arm@freebsd.org Subject: Re: Reminder: Removal of WITHOUT_ARM_EABI References: <20130820091527.42127170@bender.Home> <1377271598.1111.78.camel@revolution.hippie.lan> Date: Thu, 29 Aug 2013 19:08:09 +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: 29 Aug 2013 17:08:10.0394 (UTC) FILETIME=[56A717A0:01CEA4DA] 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, 29 Aug 2013 17:09:19 -0000 On Thu, 29 Aug 2013 19:02:48 +0200, Adrian Chadd wrote: > ok, next, try 'bt 47'. It should get a stack trace of the df pid. > > It shows its running, so.. > > > > -adrian > _______________________________________________ > 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" > That gives me this. I have to go now, but I will leave it in the debugger so I can test more when I'm back. db> bt 47 Tracing pid 47 tid 100040 td 0xc4047320 db_trace_self() at db_trace_self pc = 0xc0bb9b4c lr = 0xc093277c (db_hex2dec+0x494) sp = 0xdce8dab0 fp = 0xdce8dac8 r10 = 0xc0c9d4e0 db_hex2dec() at db_hex2dec+0x494 pc = 0xc093277c lr = 0xc0932130 (db_command_loop+0x2f4) sp = 0xdce8dad0 fp = 0xdce8db70 r4 = 0x00000000 r5 = 0x00000000 r6 = 0xc0c31c57 db_command_loop() at db_command_loop+0x2f4 pc = 0xc0932130 lr = 0xc0931e8c (db_command_loop+0x50) sp = 0xdce8db78 fp = 0xdce8db88 r4 = 0xc0c02fb7 r5 = 0xc0c19c4d r6 = 0xc0e4575c r7 = 0xdce8dd58 r8 = 0xc4047320 r9 = 0xc0ce1094 r10 = 0xc0c9d750 db_command_loop() at db_command_loop+0x50 pc = 0xc0931e8c lr = 0xc09347fc (X_db_symbol_values+0x254) sp = 0xdce8db90 fp = 0xdce8dcb0 r4 = 0x00000000 r5 = 0xdce8db98 r6 = 0xc0ce10c0 X_db_symbol_values() at X_db_symbol_values+0x254 pc = 0xc09347fc lr = 0xc0a7d034 (kdb_trap+0xd4) sp = 0xdce8dcb8 fp = 0xdce8dcd8 r4 = 0x00000000 r5 = 0x00000001 r6 = 0xc0ce10c0 r7 = 0xdce8dd58 kdb_trap() at kdb_trap+0xd4 pc = 0xc0a7d034 lr = 0xc0bca7ac (undefinedinstruction+0x204) sp = 0xdce8dce0 fp = 0xdce8dd50 r4 = 0x00000000 r5 = 0x00000000 r6 = 0xc0bca4f8 r7 = 0xe7ffffff r8 = 0xc4047320 r9 = 0xc0a7cad4 r10 = 0xdce8dd58 undefinedinstruction() at undefinedinstruction+0x204 pc = 0xc0bca7ac lr = 0xc0bbb400 (exception_exit) sp = 0xdce8dd58 fp = 0xdce8ddb8 r4 = 0xffffffff r5 = 0xffff1004 r6 = 0x00000002 r7 = 0x00000000 r8 = 0x00000001 r9 = 0xc4047320 r10 = 0x27be4eaf exception_exit() at exception_exit pc = 0xc0bbb400 lr = 0xc0a7cac4 (kdb_alt_break+0x184) sp = 0xdce8ddac fp = 0xdce8ddb8 r0 = 0xc0ce10a4 r1 = 0xc0c030ab r2 = 0x00000000 r3 = 0x60000093 r4 = 0xc3d45200 r5 = 0xc3d45288 r6 = 0x00000002 r7 = 0x00000000 r8 = 0x00000001 r9 = 0xc4047320 r10 = 0x27be4eaf r12 = 0x000000c0 kdb_alt_break() at kdb_alt_break+0x198 pc = 0xc0a7cad8 lr = 0xc0a7c950 (kdb_alt_break+0x10) sp = 0xdce8ddc0 fp = 0xdce8ddc0 r4 = 0xc3d45200 r5 = 0xc3d45288 r6 = 0x00000002 r7 = 0x00000000 kdb_alt_break() at kdb_alt_break+0x10 pc = 0xc0a7c950 lr = 0xc094c5d8 (uart_bus_ihand+0x2fc) sp = 0xdce8ddc8 fp = 0xdce8dde0 uart_bus_ihand() at uart_bus_ihand+0x2fc pc = 0xc094c5d8 lr = 0xc094d19c (uart_bus_attach+0x690) sp = 0xdce8dde8 fp = 0xdce8de20 r4 = 0x0000ff7f r5 = 0xc3d45200 r6 = 0x00040000 uart_bus_attach() at uart_bus_attach+0x690 pc = 0xc094d19c lr = 0xc0a27f7c (intr_event_handle+0x78) sp = 0xdce8de28 fp = 0xdce8de40 r4 = 0xc34c3700 r5 = 0xdce8de60 r6 = 0x00000000 r7 = 0xc3e3b340 r8 = 0x00000000 intr_event_handle() at intr_event_handle+0x78 pc = 0xc0a27f7c lr = 0xc0bbc68c (arm_handler_execute+0x54) sp = 0xdce8de48 fp = 0xdce8de58 r4 = 0xdce8de60 r5 = 0x00000021 r6 = 0xc0cc29e0 r7 = 0xc0e42ad8 r8 = 0x12a2532a r9 = 0xc6d47a95 arm_handler_execute() at arm_handler_execute+0x54 pc = 0xc0bbc68c lr = 0xc0bcef24 (irq_entry+0x9c) sp = 0xdce8de60 fp = 0xbfffe528 r4 = 0xffffffff r5 = 0xffff1004 r6 = 0x208dc014 r7 = 0x2f5b177e irq_entry() at irq_entry+0x9c pc = 0xc0bcef24 lr = 0x200eba44 (0x200eba44) sp = 0xdce8deb4 fp = 0xbfffe528 r0 = 0xa5581795 r1 = 0x209707a0 r2 = 0x0000ec90 r3 = 0x20901280 r4 = 0x27be4eaf r5 = 0x00000000 r6 = 0x208dc014 r7 = 0x2f5b177e r8 = 0x12a2532a r9 = 0xc6d47a95 r10 = 0x27be4eaf r12 = 0xc849eabc Unable to unwind into user mode Ronald. From owner-freebsd-arm@FreeBSD.ORG Thu Aug 29 17:17:22 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 7C99A7A2 for ; Thu, 29 Aug 2013 17:17:22 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-qc0-x230.google.com (mail-qc0-x230.google.com [IPv6:2607:f8b0:400d:c01::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 37C912966 for ; Thu, 29 Aug 2013 17:17:22 +0000 (UTC) Received: by mail-qc0-f176.google.com with SMTP id u20so323599qcx.7 for ; Thu, 29 Aug 2013 10:17:21 -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=iW4wxZTxmBNR9i53hknzYUaeZ8Yk/Zz+UFdEr2UK9aA=; b=zB0KWbl5On+zgni0TF2aY4hTIWD1Ku+XBFOy7E1jLab+x7qUE1nWOC8kNVNHYUNhgq nN3NWz+n9dv3xvDcoXle4bNG5uj+IvkYv8HgHxQknHOzPeQBl0ZxRWx8sbeXtIvJCPBd kxyO4pWE34U0prg/5xTdtoX67Vaxsw5hwasZK42zWLnx4IiYwp5TL+SzQeJ0yNAcA3B2 UuPyrJJCuu0F1Ovafn/XR4J2BnS5halWFtYDkMEp6we3ASM9JSYJ8Su6VAz87vHnaMcL EcmqKPe4txwneuCShH5dmGt2S+wQ2SFg1JyV+JZN+2gEuk5FU9KijF/JPFUZ3CDFmMPI 3b2Q== MIME-Version: 1.0 X-Received: by 10.229.103.135 with SMTP id k7mr5346082qco.22.1377796641285; Thu, 29 Aug 2013 10:17:21 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.224.128.70 with HTTP; Thu, 29 Aug 2013 10:17:21 -0700 (PDT) In-Reply-To: References: <20130820091527.42127170@bender.Home> <1377271598.1111.78.camel@revolution.hippie.lan> Date: Thu, 29 Aug 2013 10:17:21 -0700 X-Google-Sender-Auth: 1wO4D6O0J6MDp8aV5Q7qre1_WsY Message-ID: Subject: Re: Reminder: Removal of WITHOUT_ARM_EABI From: Adrian Chadd To: Ronald Klop 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, 29 Aug 2013 17:17:22 -0000 (top posting so one doesn't have to scroll down to the bottom to read this..) ARM people - is this useful? This looks to me like the serial console IO path to enter ddb. I guess uart_bus_attach() is the wrong function name and the real function is something inside the uart RX path. When this userland process hangs, are other processes able to run? are you able to do something like df &, have it hang in the background, then enter kdb (from the shell pid?) I wonder if this is a userland hang rather than a kernel hang.. -adrian On 29 August 2013 10:08, Ronald Klop wrote: > On Thu, 29 Aug 2013 19:02:48 +0200, Adrian Chadd > wrote: > > ok, next, try 'bt 47'. It should get a stack trace of the df pid. >> >> It shows its running, so.. >> >> >> >> -adrian >> ______________________________**_________________ >> 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 >> " >> >> > That gives me this. I have to go now, but I will leave it in the debugger > so I can test more when I'm back. > > db> bt 47 > Tracing pid 47 tid 100040 td 0xc4047320 > db_trace_self() at db_trace_self > pc = 0xc0bb9b4c lr = 0xc093277c (db_hex2dec+0x494) > sp = 0xdce8dab0 fp = 0xdce8dac8 > r10 = 0xc0c9d4e0 > db_hex2dec() at db_hex2dec+0x494 > pc = 0xc093277c lr = 0xc0932130 (db_command_loop+0x2f4) > sp = 0xdce8dad0 fp = 0xdce8db70 > r4 = 0x00000000 r5 = 0x00000000 > r6 = 0xc0c31c57 > db_command_loop() at db_command_loop+0x2f4 > pc = 0xc0932130 lr = 0xc0931e8c (db_command_loop+0x50) > sp = 0xdce8db78 fp = 0xdce8db88 > r4 = 0xc0c02fb7 r5 = 0xc0c19c4d > r6 = 0xc0e4575c r7 = 0xdce8dd58 > r8 = 0xc4047320 r9 = 0xc0ce1094 > r10 = 0xc0c9d750 > db_command_loop() at db_command_loop+0x50 > pc = 0xc0931e8c lr = 0xc09347fc (X_db_symbol_values+0x254) > sp = 0xdce8db90 fp = 0xdce8dcb0 > r4 = 0x00000000 r5 = 0xdce8db98 > r6 = 0xc0ce10c0 > X_db_symbol_values() at X_db_symbol_values+0x254 > pc = 0xc09347fc lr = 0xc0a7d034 (kdb_trap+0xd4) > sp = 0xdce8dcb8 fp = 0xdce8dcd8 > r4 = 0x00000000 r5 = 0x00000001 > r6 = 0xc0ce10c0 r7 = 0xdce8dd58 > kdb_trap() at kdb_trap+0xd4 > pc = 0xc0a7d034 lr = 0xc0bca7ac (undefinedinstruction+0x204) > sp = 0xdce8dce0 fp = 0xdce8dd50 > r4 = 0x00000000 r5 = 0x00000000 > r6 = 0xc0bca4f8 r7 = 0xe7ffffff > r8 = 0xc4047320 r9 = 0xc0a7cad4 > r10 = 0xdce8dd58 > undefinedinstruction() at undefinedinstruction+0x204 > pc = 0xc0bca7ac lr = 0xc0bbb400 (exception_exit) > sp = 0xdce8dd58 fp = 0xdce8ddb8 > r4 = 0xffffffff r5 = 0xffff1004 > r6 = 0x00000002 r7 = 0x00000000 > r8 = 0x00000001 r9 = 0xc4047320 > r10 = 0x27be4eaf > exception_exit() at exception_exit > pc = 0xc0bbb400 lr = 0xc0a7cac4 (kdb_alt_break+0x184) > sp = 0xdce8ddac fp = 0xdce8ddb8 > r0 = 0xc0ce10a4 r1 = 0xc0c030ab > r2 = 0x00000000 r3 = 0x60000093 > r4 = 0xc3d45200 r5 = 0xc3d45288 > r6 = 0x00000002 r7 = 0x00000000 > r8 = 0x00000001 r9 = 0xc4047320 > r10 = 0x27be4eaf r12 = 0x000000c0 > kdb_alt_break() at kdb_alt_break+0x198 > pc = 0xc0a7cad8 lr = 0xc0a7c950 (kdb_alt_break+0x10) > sp = 0xdce8ddc0 fp = 0xdce8ddc0 > r4 = 0xc3d45200 r5 = 0xc3d45288 > r6 = 0x00000002 r7 = 0x00000000 > kdb_alt_break() at kdb_alt_break+0x10 > pc = 0xc0a7c950 lr = 0xc094c5d8 (uart_bus_ihand+0x2fc) > sp = 0xdce8ddc8 fp = 0xdce8dde0 > uart_bus_ihand() at uart_bus_ihand+0x2fc > pc = 0xc094c5d8 lr = 0xc094d19c (uart_bus_attach+0x690) > sp = 0xdce8dde8 fp = 0xdce8de20 > r4 = 0x0000ff7f r5 = 0xc3d45200 > r6 = 0x00040000 > uart_bus_attach() at uart_bus_attach+0x690 > pc = 0xc094d19c lr = 0xc0a27f7c (intr_event_handle+0x78) > sp = 0xdce8de28 fp = 0xdce8de40 > r4 = 0xc34c3700 r5 = 0xdce8de60 > r6 = 0x00000000 r7 = 0xc3e3b340 > r8 = 0x00000000 > intr_event_handle() at intr_event_handle+0x78 > pc = 0xc0a27f7c lr = 0xc0bbc68c (arm_handler_execute+0x54) > sp = 0xdce8de48 fp = 0xdce8de58 > r4 = 0xdce8de60 r5 = 0x00000021 > r6 = 0xc0cc29e0 r7 = 0xc0e42ad8 > r8 = 0x12a2532a r9 = 0xc6d47a95 > arm_handler_execute() at arm_handler_execute+0x54 > pc = 0xc0bbc68c lr = 0xc0bcef24 (irq_entry+0x9c) > sp = 0xdce8de60 fp = 0xbfffe528 > r4 = 0xffffffff r5 = 0xffff1004 > r6 = 0x208dc014 r7 = 0x2f5b177e > irq_entry() at irq_entry+0x9c > pc = 0xc0bcef24 lr = 0x200eba44 (0x200eba44) > sp = 0xdce8deb4 fp = 0xbfffe528 > r0 = 0xa5581795 r1 = 0x209707a0 > r2 = 0x0000ec90 r3 = 0x20901280 > r4 = 0x27be4eaf r5 = 0x00000000 > r6 = 0x208dc014 r7 = 0x2f5b177e > r8 = 0x12a2532a r9 = 0xc6d47a95 > r10 = 0x27be4eaf r12 = 0xc849eabc > Unable to unwind into user mode > > > > Ronald. > ______________________________**_________________ > 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 Aug 29 17:25:03 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id D7CD5C93; Thu, 29 Aug 2013 17:25:03 +0000 (UTC) (envelope-from jmg@h2.funkthat.com) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id ABA212A0E; Thu, 29 Aug 2013 17:25:03 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id r7THP3IT031885 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 29 Aug 2013 10:25:03 -0700 (PDT) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id r7THP2sf031884; Thu, 29 Aug 2013 10:25:02 -0700 (PDT) (envelope-from jmg) Date: Thu, 29 Aug 2013 10:25:02 -0700 From: John-Mark Gurney To: Adrian Chadd Subject: Re: Reminder: Removal of WITHOUT_ARM_EABI Message-ID: <20130829172502.GY29777@funkthat.com> Mail-Followup-To: Adrian Chadd , Ronald Klop , "freebsd-arm@freebsd.org" References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Thu, 29 Aug 2013 10:25:03 -0700 (PDT) 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: Thu, 29 Aug 2013 17:25:03 -0000 Adrian Chadd wrote this message on Thu, Aug 29, 2013 at 10:17 -0700: > (top posting so one doesn't have to scroll down to the bottom to read > this..) > > ARM people - is this useful? This looks to me like the serial console IO > path to enter ddb. I guess uart_bus_attach() is the wrong function name and > the real function is something inside the uart RX path. > > When this userland process hangs, are other processes able to run? are you > able to do something like df &, have it hang in the background, then enter > kdb (from the shell pid?) > > I wonder if this is a userland hang rather than a kernel hang.. I was wondering if they could run it under gdb and see where it hangs in df... Also, the report seems like disk io is hung up, because they can run processes that are in cache, but new processes that haven't been run yet hang... though why they can't ctrl-t is weird, that should be possible if they can kill -9 from another shell.. > On 29 August 2013 10:08, Ronald Klop wrote: > > > On Thu, 29 Aug 2013 19:02:48 +0200, Adrian Chadd > > wrote: > > > > ok, next, try 'bt 47'. It should get a stack trace of the df pid. > >> > >> It shows its running, so.. > >> > >> > >> > >> -adrian > >> ______________________________**_________________ > >> 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 > >> " > >> > >> > > That gives me this. I have to go now, but I will leave it in the debugger > > so I can test more when I'm back. > > > > db> bt 47 > > Tracing pid 47 tid 100040 td 0xc4047320 > > db_trace_self() at db_trace_self > > pc = 0xc0bb9b4c lr = 0xc093277c (db_hex2dec+0x494) > > sp = 0xdce8dab0 fp = 0xdce8dac8 > > r10 = 0xc0c9d4e0 > > db_hex2dec() at db_hex2dec+0x494 > > pc = 0xc093277c lr = 0xc0932130 (db_command_loop+0x2f4) > > sp = 0xdce8dad0 fp = 0xdce8db70 > > r4 = 0x00000000 r5 = 0x00000000 > > r6 = 0xc0c31c57 > > db_command_loop() at db_command_loop+0x2f4 > > pc = 0xc0932130 lr = 0xc0931e8c (db_command_loop+0x50) > > sp = 0xdce8db78 fp = 0xdce8db88 > > r4 = 0xc0c02fb7 r5 = 0xc0c19c4d > > r6 = 0xc0e4575c r7 = 0xdce8dd58 > > r8 = 0xc4047320 r9 = 0xc0ce1094 > > r10 = 0xc0c9d750 > > db_command_loop() at db_command_loop+0x50 > > pc = 0xc0931e8c lr = 0xc09347fc (X_db_symbol_values+0x254) > > sp = 0xdce8db90 fp = 0xdce8dcb0 > > r4 = 0x00000000 r5 = 0xdce8db98 > > r6 = 0xc0ce10c0 > > X_db_symbol_values() at X_db_symbol_values+0x254 > > pc = 0xc09347fc lr = 0xc0a7d034 (kdb_trap+0xd4) > > sp = 0xdce8dcb8 fp = 0xdce8dcd8 > > r4 = 0x00000000 r5 = 0x00000001 > > r6 = 0xc0ce10c0 r7 = 0xdce8dd58 > > kdb_trap() at kdb_trap+0xd4 > > pc = 0xc0a7d034 lr = 0xc0bca7ac (undefinedinstruction+0x204) > > sp = 0xdce8dce0 fp = 0xdce8dd50 > > r4 = 0x00000000 r5 = 0x00000000 > > r6 = 0xc0bca4f8 r7 = 0xe7ffffff > > r8 = 0xc4047320 r9 = 0xc0a7cad4 > > r10 = 0xdce8dd58 > > undefinedinstruction() at undefinedinstruction+0x204 > > pc = 0xc0bca7ac lr = 0xc0bbb400 (exception_exit) > > sp = 0xdce8dd58 fp = 0xdce8ddb8 > > r4 = 0xffffffff r5 = 0xffff1004 > > r6 = 0x00000002 r7 = 0x00000000 > > r8 = 0x00000001 r9 = 0xc4047320 > > r10 = 0x27be4eaf > > exception_exit() at exception_exit > > pc = 0xc0bbb400 lr = 0xc0a7cac4 (kdb_alt_break+0x184) > > sp = 0xdce8ddac fp = 0xdce8ddb8 > > r0 = 0xc0ce10a4 r1 = 0xc0c030ab > > r2 = 0x00000000 r3 = 0x60000093 > > r4 = 0xc3d45200 r5 = 0xc3d45288 > > r6 = 0x00000002 r7 = 0x00000000 > > r8 = 0x00000001 r9 = 0xc4047320 > > r10 = 0x27be4eaf r12 = 0x000000c0 > > kdb_alt_break() at kdb_alt_break+0x198 > > pc = 0xc0a7cad8 lr = 0xc0a7c950 (kdb_alt_break+0x10) > > sp = 0xdce8ddc0 fp = 0xdce8ddc0 > > r4 = 0xc3d45200 r5 = 0xc3d45288 > > r6 = 0x00000002 r7 = 0x00000000 > > kdb_alt_break() at kdb_alt_break+0x10 > > pc = 0xc0a7c950 lr = 0xc094c5d8 (uart_bus_ihand+0x2fc) > > sp = 0xdce8ddc8 fp = 0xdce8dde0 > > uart_bus_ihand() at uart_bus_ihand+0x2fc > > pc = 0xc094c5d8 lr = 0xc094d19c (uart_bus_attach+0x690) > > sp = 0xdce8dde8 fp = 0xdce8de20 > > r4 = 0x0000ff7f r5 = 0xc3d45200 > > r6 = 0x00040000 > > uart_bus_attach() at uart_bus_attach+0x690 > > pc = 0xc094d19c lr = 0xc0a27f7c (intr_event_handle+0x78) > > sp = 0xdce8de28 fp = 0xdce8de40 > > r4 = 0xc34c3700 r5 = 0xdce8de60 > > r6 = 0x00000000 r7 = 0xc3e3b340 > > r8 = 0x00000000 > > intr_event_handle() at intr_event_handle+0x78 > > pc = 0xc0a27f7c lr = 0xc0bbc68c (arm_handler_execute+0x54) > > sp = 0xdce8de48 fp = 0xdce8de58 > > r4 = 0xdce8de60 r5 = 0x00000021 > > r6 = 0xc0cc29e0 r7 = 0xc0e42ad8 > > r8 = 0x12a2532a r9 = 0xc6d47a95 > > arm_handler_execute() at arm_handler_execute+0x54 > > pc = 0xc0bbc68c lr = 0xc0bcef24 (irq_entry+0x9c) > > sp = 0xdce8de60 fp = 0xbfffe528 > > r4 = 0xffffffff r5 = 0xffff1004 > > r6 = 0x208dc014 r7 = 0x2f5b177e > > irq_entry() at irq_entry+0x9c > > pc = 0xc0bcef24 lr = 0x200eba44 (0x200eba44) > > sp = 0xdce8deb4 fp = 0xbfffe528 > > r0 = 0xa5581795 r1 = 0x209707a0 > > r2 = 0x0000ec90 r3 = 0x20901280 > > r4 = 0x27be4eaf r5 = 0x00000000 > > r6 = 0x208dc014 r7 = 0x2f5b177e > > r8 = 0x12a2532a r9 = 0xc6d47a95 > > r10 = 0x27be4eaf r12 = 0xc849eabc > > Unable to unwind into user mode > > > > > > > > Ronald. > > ______________________________**_________________ > > 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" -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-arm@FreeBSD.ORG Thu Aug 29 17:25: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 A7F23CE0 for ; Thu, 29 Aug 2013 17:25:32 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-oa0-f41.google.com (mail-oa0-f41.google.com [209.85.219.41]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 695882A14 for ; Thu, 29 Aug 2013 17:25:32 +0000 (UTC) Received: by mail-oa0-f41.google.com with SMTP id j17so791367oag.28 for ; Thu, 29 Aug 2013 10:25:31 -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=Ba2uf4qgevPMRjMPrkaipYj5JkM/Uw7h7P0WW1m0TyQ=; b=Q2L8BN0mErlHTFTZjWG2cxaQOaf33en3kLl1hfCBy9SUS26YFqAMET2eVv0QwB5Sv/ Ay3Ebg4k81421PQHD9aJIDmah5DrLUuSZs4lquIx2d178FFZB+N0fTqYFdkkMwKU9D9d c4NJf9wUs/5gE+pyb+PI+envF+qDuGKUcszxfRS+1jLKxUjB4GGqsuFJQPP5Sirtlpth gfTOa+lKNtZzZx0V6gQsm7EpcT+OQRzt33dpBR9VqouBxLGBrRvTClrhhbQYZC3y6GQj Rsf7AMivrP8XaX8cHCkFJcDSMzCIx/R6gGtMm3LXLl4jx5CwPt4Ojlf6JSXvO8M9PQCv nl9g== X-Gm-Message-State: ALoCoQldwCMwdzuZzlXtXphEBdomPGtJ1nPdYYdshnGR6+8HwscjHw1VIEPuXTjXlabG0OsD3dtX X-Received: by 10.182.134.229 with SMTP id pn5mr3147334obb.88.1377797131658; Thu, 29 Aug 2013 10:25:31 -0700 (PDT) Received: from monkey-bot.int.fusionio.com ([209.117.142.2]) by mx.google.com with ESMTPSA id tz10sm32444786obc.10.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 29 Aug 2013 10:25:30 -0700 (PDT) Sender: Warner Losh Subject: Re: Reminder: Removal of WITHOUT_ARM_EABI Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: Date: Thu, 29 Aug 2013 11:25:28 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <6046B66D-5F4C-4E8D-923A-3E26DED5DD8F@bsdimp.com> References: <20130820091527.42127170@bender.Home> <1377271598.1111.78.camel@revolution.hippie.lan> To: Adrian Chadd 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: Thu, 29 Aug 2013 17:25:32 -0000 On Aug 29, 2013, at 11:17 AM, Adrian Chadd wrote: > (top posting so one doesn't have to scroll down to the bottom to read > this..) >=20 > ARM people - is this useful? This looks to me like the serial console = IO > path to enter ddb. I guess uart_bus_attach() is the wrong function = name and > the real function is something inside the uart RX path This stack trace is poo. These routines long ago finished running, and = certainly wouldn't be running in the context of df. > When this userland process hangs, are other processes able to run? are = you > able to do something like df &, have it hang in the background, then = enter > kdb (from the shell pid?) >=20 > I wonder if this is a userland hang rather than a kernel hang.. Not being able to ^C suggests that the process is in a "disk" wait or = other uninterruptible wait (or it has tripped an infinite loop in the = kernel). That needs to be tracked down. why does df show up as having = no wchan and no wmesg, yet is hung and not responding to ^C? Warner >=20 > -adrian >=20 >=20 >=20 > On 29 August 2013 10:08, Ronald Klop = wrote: >=20 >> On Thu, 29 Aug 2013 19:02:48 +0200, Adrian Chadd >> wrote: >>=20 >> ok, next, try 'bt 47'. It should get a stack trace of the df pid. >>>=20 >>> It shows its running, so.. >>>=20 >>>=20 >>>=20 >>> -adrian >>> ______________________________**_________________ >>> 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 >> That gives me this. I have to go now, but I will leave it in the = debugger >> so I can test more when I'm back. >>=20 >> db> bt 47 >> Tracing pid 47 tid 100040 td 0xc4047320 >> db_trace_self() at db_trace_self >> pc =3D 0xc0bb9b4c lr =3D 0xc093277c (db_hex2dec+0x494) >> sp =3D 0xdce8dab0 fp =3D 0xdce8dac8 >> r10 =3D 0xc0c9d4e0 >> db_hex2dec() at db_hex2dec+0x494 >> pc =3D 0xc093277c lr =3D 0xc0932130 (db_command_loop+0x2f4) >> sp =3D 0xdce8dad0 fp =3D 0xdce8db70 >> r4 =3D 0x00000000 r5 =3D 0x00000000 >> r6 =3D 0xc0c31c57 >> db_command_loop() at db_command_loop+0x2f4 >> pc =3D 0xc0932130 lr =3D 0xc0931e8c (db_command_loop+0x50) >> sp =3D 0xdce8db78 fp =3D 0xdce8db88 >> r4 =3D 0xc0c02fb7 r5 =3D 0xc0c19c4d >> r6 =3D 0xc0e4575c r7 =3D 0xdce8dd58 >> r8 =3D 0xc4047320 r9 =3D 0xc0ce1094 >> r10 =3D 0xc0c9d750 >> db_command_loop() at db_command_loop+0x50 >> pc =3D 0xc0931e8c lr =3D 0xc09347fc = (X_db_symbol_values+0x254) >> sp =3D 0xdce8db90 fp =3D 0xdce8dcb0 >> r4 =3D 0x00000000 r5 =3D 0xdce8db98 >> r6 =3D 0xc0ce10c0 >> X_db_symbol_values() at X_db_symbol_values+0x254 >> pc =3D 0xc09347fc lr =3D 0xc0a7d034 (kdb_trap+0xd4) >> sp =3D 0xdce8dcb8 fp =3D 0xdce8dcd8 >> r4 =3D 0x00000000 r5 =3D 0x00000001 >> r6 =3D 0xc0ce10c0 r7 =3D 0xdce8dd58 >> kdb_trap() at kdb_trap+0xd4 >> pc =3D 0xc0a7d034 lr =3D 0xc0bca7ac = (undefinedinstruction+0x204) >> sp =3D 0xdce8dce0 fp =3D 0xdce8dd50 >> r4 =3D 0x00000000 r5 =3D 0x00000000 >> r6 =3D 0xc0bca4f8 r7 =3D 0xe7ffffff >> r8 =3D 0xc4047320 r9 =3D 0xc0a7cad4 >> r10 =3D 0xdce8dd58 >> undefinedinstruction() at undefinedinstruction+0x204 >> pc =3D 0xc0bca7ac lr =3D 0xc0bbb400 (exception_exit) >> sp =3D 0xdce8dd58 fp =3D 0xdce8ddb8 >> r4 =3D 0xffffffff r5 =3D 0xffff1004 >> r6 =3D 0x00000002 r7 =3D 0x00000000 >> r8 =3D 0x00000001 r9 =3D 0xc4047320 >> r10 =3D 0x27be4eaf >> exception_exit() at exception_exit >> pc =3D 0xc0bbb400 lr =3D 0xc0a7cac4 (kdb_alt_break+0x184) >> sp =3D 0xdce8ddac fp =3D 0xdce8ddb8 >> r0 =3D 0xc0ce10a4 r1 =3D 0xc0c030ab >> r2 =3D 0x00000000 r3 =3D 0x60000093 >> r4 =3D 0xc3d45200 r5 =3D 0xc3d45288 >> r6 =3D 0x00000002 r7 =3D 0x00000000 >> r8 =3D 0x00000001 r9 =3D 0xc4047320 >> r10 =3D 0x27be4eaf r12 =3D 0x000000c0 >> kdb_alt_break() at kdb_alt_break+0x198 >> pc =3D 0xc0a7cad8 lr =3D 0xc0a7c950 (kdb_alt_break+0x10) >> sp =3D 0xdce8ddc0 fp =3D 0xdce8ddc0 >> r4 =3D 0xc3d45200 r5 =3D 0xc3d45288 >> r6 =3D 0x00000002 r7 =3D 0x00000000 >> kdb_alt_break() at kdb_alt_break+0x10 >> pc =3D 0xc0a7c950 lr =3D 0xc094c5d8 (uart_bus_ihand+0x2fc) >> sp =3D 0xdce8ddc8 fp =3D 0xdce8dde0 >> uart_bus_ihand() at uart_bus_ihand+0x2fc >> pc =3D 0xc094c5d8 lr =3D 0xc094d19c (uart_bus_attach+0x690) >> sp =3D 0xdce8dde8 fp =3D 0xdce8de20 >> r4 =3D 0x0000ff7f r5 =3D 0xc3d45200 >> r6 =3D 0x00040000 >> uart_bus_attach() at uart_bus_attach+0x690 >> pc =3D 0xc094d19c lr =3D 0xc0a27f7c (intr_event_handle+0x78) >> sp =3D 0xdce8de28 fp =3D 0xdce8de40 >> r4 =3D 0xc34c3700 r5 =3D 0xdce8de60 >> r6 =3D 0x00000000 r7 =3D 0xc3e3b340 >> r8 =3D 0x00000000 >> intr_event_handle() at intr_event_handle+0x78 >> pc =3D 0xc0a27f7c lr =3D 0xc0bbc68c = (arm_handler_execute+0x54) >> sp =3D 0xdce8de48 fp =3D 0xdce8de58 >> r4 =3D 0xdce8de60 r5 =3D 0x00000021 >> r6 =3D 0xc0cc29e0 r7 =3D 0xc0e42ad8 >> r8 =3D 0x12a2532a r9 =3D 0xc6d47a95 >> arm_handler_execute() at arm_handler_execute+0x54 >> pc =3D 0xc0bbc68c lr =3D 0xc0bcef24 (irq_entry+0x9c) >> sp =3D 0xdce8de60 fp =3D 0xbfffe528 >> r4 =3D 0xffffffff r5 =3D 0xffff1004 >> r6 =3D 0x208dc014 r7 =3D 0x2f5b177e >> irq_entry() at irq_entry+0x9c >> pc =3D 0xc0bcef24 lr =3D 0x200eba44 (0x200eba44) >> sp =3D 0xdce8deb4 fp =3D 0xbfffe528 >> r0 =3D 0xa5581795 r1 =3D 0x209707a0 >> r2 =3D 0x0000ec90 r3 =3D 0x20901280 >> r4 =3D 0x27be4eaf r5 =3D 0x00000000 >> r6 =3D 0x208dc014 r7 =3D 0x2f5b177e >> r8 =3D 0x12a2532a r9 =3D 0xc6d47a95 >> r10 =3D 0x27be4eaf r12 =3D 0xc849eabc >> Unable to unwind into user mode >>=20 >>=20 >>=20 >> Ronald. >> ______________________________**_________________ >> 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" From owner-freebsd-arm@FreeBSD.ORG Thu Aug 29 17:32: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 905E1EF8 for ; Thu, 29 Aug 2013 17:32:04 +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 3A2922A7F for ; Thu, 29 Aug 2013 17:32:03 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by galore.getmail.no (Postfix) with ESMTP id 5178BE009D for ; Thu, 29 Aug 2013 19:22:05 +0200 (CEST) X-Spam-Flag: NO X-Spam-Score: -2.76 X-Spam-Level: X-Spam-Status: No, score=-2.76 tagged_above=-10 required=6.6 tests=[ALL_TRUSTED=-1, BAYES_00=-1.9, DKIM_SIGNED=0.1, T_BIG_HEADERS_2K=0.01, T_DKIM_INVALID=0.01, T_KHOP_THREADED=-0.01, T_LONG_HEADER_LINE_80=0.01, T_NICE_REPLY_A=0.01, T_UNKNOWN_ORIGIN=0.01] autolearn=no Authentication-Results: galore.get.c.bitbit.net (amavisd-new); dkim=neutral reason="invalid (public key: not available)" 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 4CVoURal_xVm for ; Thu, 29 Aug 2013 19:22:04 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by galore.getmail.no (Postfix) with ESMTP id A8E95E0080 for ; Thu, 29 Aug 2013 19:22:04 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.7.1 galore.getmail.no A8E95E0080 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=getmail.no; s=8A9C8B4C-D727-11E2-8095-B6466E6B3FA2; t=1377796924; bh=fs65MJu+LzlLYDZnudrAB8SyKhNmolkmGZuJznh5K8g=; h=Date:From:To:Subject:Message-Id:Mime-Version:Content-Type: Content-Transfer-Encoding; b=BQaYMhCvmVkmBUf3RV7tZ+9JrOx2g1aUNBhpDzwWI+MHWNDx/t2KrEgvr6ZBF8M9T DsoLfq81dBvhIiO5jjQNgTxbkytfV9acbCnCQDNAQrCEnvk7k/FPBb0tR3WZLRJole drNt/Sst7vkv982xJ4xY079566+KIFcTbhPb119w= 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 Bc-AaRCxO38b for ; Thu, 29 Aug 2013 19:22:04 +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 8024FE008B for ; Thu, 29 Aug 2013 19:22:04 +0200 (CEST) Date: Thu, 29 Aug 2013 19:22:04 +0200 From: Torfinn Ingolfsen To: freebsd-arm@FreeBSD.org Subject: Re: Reminder: Removal of WITHOUT_ARM_EABI Message-Id: <20130829192204.d97dcc714deb96ae5ace2b93@getmail.no> In-Reply-To: References: <20130820091527.42127170@bender.Home> <1377271598.1111.78.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, 29 Aug 2013 17:32:04 -0000 On Thu, 29 Aug 2013 10:17:21 -0700 Adrian Chadd wrote: > (top posting so one doesn't have to scroll down to the bottom to read > this..) Everyone: it would be much easier if _everyone_ trimmed their quotes, instead of being lazy. -- Torfinn Ingolfsen From owner-freebsd-arm@FreeBSD.ORG Thu Aug 29 17:35: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 D18B716F; Thu, 29 Aug 2013 17:35:20 +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 8D9722AA4; Thu, 29 Aug 2013 17:35:20 +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 1VF67r-0002ZY-AY; Thu, 29 Aug 2013 17:35:19 +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 r7THZGsM055897; Thu, 29 Aug 2013 11:35:16 -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: U2FsdGVkX19qeV/XETxWy/nnvyzUHyB6 Subject: Re: Reminder: Removal of WITHOUT_ARM_EABI From: Ian Lepore To: Warner Losh In-Reply-To: <6046B66D-5F4C-4E8D-923A-3E26DED5DD8F@bsdimp.com> References: <20130820091527.42127170@bender.Home> <1377271598.1111.78.camel@revolution.hippie.lan> <6046B66D-5F4C-4E8D-923A-3E26DED5DD8F@bsdimp.com> Content-Type: text/plain; charset="us-ascii" Date: Thu, 29 Aug 2013 11:35:16 -0600 Message-ID: <1377797716.1111.288.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: Thu, 29 Aug 2013 17:35:20 -0000 On Thu, 2013-08-29 at 11:25 -0600, Warner Losh wrote: > On Aug 29, 2013, at 11:17 AM, Adrian Chadd wrote: > > > (top posting so one doesn't have to scroll down to the bottom to read > > this..) > > > > ARM people - is this useful? This looks to me like the serial console IO > > path to enter ddb. I guess uart_bus_attach() is the wrong function name and > > the real function is something inside the uart RX path > > This stack trace is poo. These routines long ago finished running, and certainly wouldn't be running in the context of df. > No, look at the offset: uart_bus_attach+0x690... 0x690 is far beyond the end of attach(), it's some static function that follows attach() in the source. The backtrace just lists the nearest preceeding symbol. > > When this userland process hangs, are other processes able to run? are you > > able to do something like df &, have it hang in the background, then enter > > kdb (from the shell pid?) > > > > I wonder if this is a userland hang rather than a kernel hang.. > > Not being able to ^C suggests that the process is in a "disk" wait or other uninterruptible wait (or it has tripped an infinite loop in the kernel). That needs to be tracked down. why does df show up as having no wchan and no wmesg, yet is hung and not responding to ^C? > It DOES respond to ^C, it DOESN'T respond to ^T. Hitting ^T doesn't lock it up further eitehr, you can still ^C after trying ^T. The thing that fails to respond to ^C is if you try to launch top or ps or some other tool from a different shell. -- Ian > Warner > > > > > -adrian > > > > > > > > On 29 August 2013 10:08, Ronald Klop wrote: > > > >> On Thu, 29 Aug 2013 19:02:48 +0200, Adrian Chadd > >> wrote: > >> > >> ok, next, try 'bt 47'. It should get a stack trace of the df pid. > >>> > >>> It shows its running, so.. > >>> > >>> > >>> > >>> -adrian > >>> ______________________________**_________________ > >>> 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 > >>> " > >>> > >>> > >> That gives me this. I have to go now, but I will leave it in the debugger > >> so I can test more when I'm back. > >> > >> db> bt 47 > >> Tracing pid 47 tid 100040 td 0xc4047320 > >> db_trace_self() at db_trace_self > >> pc = 0xc0bb9b4c lr = 0xc093277c (db_hex2dec+0x494) > >> sp = 0xdce8dab0 fp = 0xdce8dac8 > >> r10 = 0xc0c9d4e0 > >> db_hex2dec() at db_hex2dec+0x494 > >> pc = 0xc093277c lr = 0xc0932130 (db_command_loop+0x2f4) > >> sp = 0xdce8dad0 fp = 0xdce8db70 > >> r4 = 0x00000000 r5 = 0x00000000 > >> r6 = 0xc0c31c57 > >> db_command_loop() at db_command_loop+0x2f4 > >> pc = 0xc0932130 lr = 0xc0931e8c (db_command_loop+0x50) > >> sp = 0xdce8db78 fp = 0xdce8db88 > >> r4 = 0xc0c02fb7 r5 = 0xc0c19c4d > >> r6 = 0xc0e4575c r7 = 0xdce8dd58 > >> r8 = 0xc4047320 r9 = 0xc0ce1094 > >> r10 = 0xc0c9d750 > >> db_command_loop() at db_command_loop+0x50 > >> pc = 0xc0931e8c lr = 0xc09347fc (X_db_symbol_values+0x254) > >> sp = 0xdce8db90 fp = 0xdce8dcb0 > >> r4 = 0x00000000 r5 = 0xdce8db98 > >> r6 = 0xc0ce10c0 > >> X_db_symbol_values() at X_db_symbol_values+0x254 > >> pc = 0xc09347fc lr = 0xc0a7d034 (kdb_trap+0xd4) > >> sp = 0xdce8dcb8 fp = 0xdce8dcd8 > >> r4 = 0x00000000 r5 = 0x00000001 > >> r6 = 0xc0ce10c0 r7 = 0xdce8dd58 > >> kdb_trap() at kdb_trap+0xd4 > >> pc = 0xc0a7d034 lr = 0xc0bca7ac (undefinedinstruction+0x204) > >> sp = 0xdce8dce0 fp = 0xdce8dd50 > >> r4 = 0x00000000 r5 = 0x00000000 > >> r6 = 0xc0bca4f8 r7 = 0xe7ffffff > >> r8 = 0xc4047320 r9 = 0xc0a7cad4 > >> r10 = 0xdce8dd58 > >> undefinedinstruction() at undefinedinstruction+0x204 > >> pc = 0xc0bca7ac lr = 0xc0bbb400 (exception_exit) > >> sp = 0xdce8dd58 fp = 0xdce8ddb8 > >> r4 = 0xffffffff r5 = 0xffff1004 > >> r6 = 0x00000002 r7 = 0x00000000 > >> r8 = 0x00000001 r9 = 0xc4047320 > >> r10 = 0x27be4eaf > >> exception_exit() at exception_exit > >> pc = 0xc0bbb400 lr = 0xc0a7cac4 (kdb_alt_break+0x184) > >> sp = 0xdce8ddac fp = 0xdce8ddb8 > >> r0 = 0xc0ce10a4 r1 = 0xc0c030ab > >> r2 = 0x00000000 r3 = 0x60000093 > >> r4 = 0xc3d45200 r5 = 0xc3d45288 > >> r6 = 0x00000002 r7 = 0x00000000 > >> r8 = 0x00000001 r9 = 0xc4047320 > >> r10 = 0x27be4eaf r12 = 0x000000c0 > >> kdb_alt_break() at kdb_alt_break+0x198 > >> pc = 0xc0a7cad8 lr = 0xc0a7c950 (kdb_alt_break+0x10) > >> sp = 0xdce8ddc0 fp = 0xdce8ddc0 > >> r4 = 0xc3d45200 r5 = 0xc3d45288 > >> r6 = 0x00000002 r7 = 0x00000000 > >> kdb_alt_break() at kdb_alt_break+0x10 > >> pc = 0xc0a7c950 lr = 0xc094c5d8 (uart_bus_ihand+0x2fc) > >> sp = 0xdce8ddc8 fp = 0xdce8dde0 > >> uart_bus_ihand() at uart_bus_ihand+0x2fc > >> pc = 0xc094c5d8 lr = 0xc094d19c (uart_bus_attach+0x690) > >> sp = 0xdce8dde8 fp = 0xdce8de20 > >> r4 = 0x0000ff7f r5 = 0xc3d45200 > >> r6 = 0x00040000 > >> uart_bus_attach() at uart_bus_attach+0x690 > >> pc = 0xc094d19c lr = 0xc0a27f7c (intr_event_handle+0x78) > >> sp = 0xdce8de28 fp = 0xdce8de40 > >> r4 = 0xc34c3700 r5 = 0xdce8de60 > >> r6 = 0x00000000 r7 = 0xc3e3b340 > >> r8 = 0x00000000 > >> intr_event_handle() at intr_event_handle+0x78 > >> pc = 0xc0a27f7c lr = 0xc0bbc68c (arm_handler_execute+0x54) > >> sp = 0xdce8de48 fp = 0xdce8de58 > >> r4 = 0xdce8de60 r5 = 0x00000021 > >> r6 = 0xc0cc29e0 r7 = 0xc0e42ad8 > >> r8 = 0x12a2532a r9 = 0xc6d47a95 > >> arm_handler_execute() at arm_handler_execute+0x54 > >> pc = 0xc0bbc68c lr = 0xc0bcef24 (irq_entry+0x9c) > >> sp = 0xdce8de60 fp = 0xbfffe528 > >> r4 = 0xffffffff r5 = 0xffff1004 > >> r6 = 0x208dc014 r7 = 0x2f5b177e > >> irq_entry() at irq_entry+0x9c > >> pc = 0xc0bcef24 lr = 0x200eba44 (0x200eba44) > >> sp = 0xdce8deb4 fp = 0xbfffe528 > >> r0 = 0xa5581795 r1 = 0x209707a0 > >> r2 = 0x0000ec90 r3 = 0x20901280 > >> r4 = 0x27be4eaf r5 = 0x00000000 > >> r6 = 0x208dc014 r7 = 0x2f5b177e > >> r8 = 0x12a2532a r9 = 0xc6d47a95 > >> r10 = 0x27be4eaf r12 = 0xc849eabc > >> Unable to unwind into user mode > >> > >> > >> > >> Ronald. > >> ______________________________**_________________ > >> 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" > > _______________________________________________ > 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 Aug 29 17:36: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 B66EA1EB for ; Thu, 29 Aug 2013 17:36:53 +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 8560D2AC3 for ; Thu, 29 Aug 2013 17:36:53 +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 1VF69M-0003fA-86; Thu, 29 Aug 2013 17:36:52 +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 r7THanfn055906; Thu, 29 Aug 2013 11:36:49 -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: U2FsdGVkX19AFjXcArYYy/luPXpvrGzQ Subject: Re: Reminder: Removal of WITHOUT_ARM_EABI From: Ian Lepore To: Torfinn Ingolfsen In-Reply-To: <20130829192204.d97dcc714deb96ae5ace2b93@getmail.no> References: <20130820091527.42127170@bender.Home> <1377271598.1111.78.camel@revolution.hippie.lan> <20130829192204.d97dcc714deb96ae5ace2b93@getmail.no> Content-Type: text/plain; charset="us-ascii" Date: Thu, 29 Aug 2013 11:36:49 -0600 Message-ID: <1377797809.1111.290.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, 29 Aug 2013 17:36:53 -0000 On Thu, 2013-08-29 at 19:22 +0200, Torfinn Ingolfsen wrote: > On Thu, 29 Aug 2013 10:17:21 -0700 > Adrian Chadd wrote: > > > (top posting so one doesn't have to scroll down to the bottom to read > > this..) > > Everyone: it would be much easier if _everyone_ trimmed their quotes, instead of being lazy. Yeah. Or not. Some of us rather like that context right there ready to be referred to while replying, rather than spelunking through emails from days ago trying to find the relevant bits you'd like to quote. -- Ian From owner-freebsd-arm@FreeBSD.ORG Thu Aug 29 17:38:45 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 A4F5347B for ; Thu, 29 Aug 2013 17:38:45 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-qc0-x22d.google.com (mail-qc0-x22d.google.com [IPv6:2607:f8b0:400d:c01::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 5F7E72AF1 for ; Thu, 29 Aug 2013 17:38:45 +0000 (UTC) Received: by mail-qc0-f173.google.com with SMTP id z10so410254qcx.4 for ; Thu, 29 Aug 2013 10:38:44 -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=TOuNcSvwXF7qsoy1jbD9EmejG5Po4pfim+0H/0VY4MA=; b=Egnn/zsr6fsjDuiDoC8TsU9BObg7OFU9X2LRRIOUMCiEoVYeVzyUNA5PdYzWR82pEK GCM1cbOrZW4hBliK+qM1JyoMYopRvOFIZMssozKzR6KN0J1J5vlyUonr9l3FzP7X/kwE Mocxz5xFFlYEwJpGkRUKXVAtYpKiy/Nfc6Kwn69oxW5/CmKJLzjR1eD5dbv/Se/+P37d ZRoeExFdJCA5Bz4/1cbBrXn/BOaAZZpR6irCDqtgYqOL58OWQtPCCfF2SGAFpMHZrdMH ZLthOwsP6eQbXyLw74xiX78RwHziGvyEcJ5Hx82Gvd5XZHXa/IEzSLwU8vnJUMfxwRVA Q9tA== MIME-Version: 1.0 X-Received: by 10.229.214.200 with SMTP id hb8mr5592682qcb.1.1377797924440; Thu, 29 Aug 2013 10:38:44 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.224.128.70 with HTTP; Thu, 29 Aug 2013 10:38:44 -0700 (PDT) In-Reply-To: <6046B66D-5F4C-4E8D-923A-3E26DED5DD8F@bsdimp.com> References: <20130820091527.42127170@bender.Home> <1377271598.1111.78.camel@revolution.hippie.lan> <6046B66D-5F4C-4E8D-923A-3E26DED5DD8F@bsdimp.com> Date: Thu, 29 Aug 2013 10:38:44 -0700 X-Google-Sender-Auth: fNMckvKVSQnHN_2_y_ll3h9r4CM Message-ID: Subject: Re: Reminder: Removal of WITHOUT_ARM_EABI From: Adrian Chadd To: Warner Losh Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 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: Thu, 29 Aug 2013 17:38:45 -0000 On 29 August 2013 10:25, Warner Losh wrote: > > On Aug 29, 2013, at 11:17 AM, Adrian Chadd wrote: > > > (top posting so one doesn't have to scroll down to the bottom to read > > this..) > > > > ARM people - is this useful? This looks to me like the serial console IO > > path to enter ddb. I guess uart_bus_attach() is the wrong function name > and > > the real function is something inside the uart RX path > > This stack trace is poo. These routines long ago finished running, and > certainly wouldn't be running in the context of df. They'd be running if he hit the magic "please sir, may I enter ddb?" routine. The attach function is just ddb getting the symbol lookup wrong - you'd have to run (arm) addr2line to get the PC -> symbol. But the wchan shows its running, not that it's spun in the kernel. So, either it's running and doign ridiculous amounts of syscalls in some kind of loop, or it's actually spinning in userland. Re jmg - yeah, maybe running it in userland gdb will shed more light. -adrian From owner-freebsd-arm@FreeBSD.ORG Thu Aug 29 20:39: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 570627C8 for ; Thu, 29 Aug 2013 20:39:29 +0000 (UTC) (envelope-from garmitage@swin.edu.au) Received: from gpo4.cc.swin.edu.au (gpo4.cc.swin.edu.au [136.186.1.33]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id C10A02786 for ; Thu, 29 Aug 2013 20:39:28 +0000 (UTC) Received: from [136.186.229.37] (garmitage.caia.swin.edu.au [136.186.229.37]) by gpo4.cc.swin.edu.au (8.14.3/8.14.3) with ESMTP id r7TKcuBm025570 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 30 Aug 2013 06:39:16 +1000 Message-ID: <521FB160.9010008@swin.edu.au> Date: Fri, 30 Aug 2013 06:38:56 +1000 From: grenville armitage User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:16.0) Gecko/20121107 Thunderbird/16.0.2 MIME-Version: 1.0 To: freebsd-arm@freebsd.org Subject: sidebar... Re: Reminder: Removal of WITHOUT_ARM_EABI References: <20130820091527.42127170@bender.Home> <1377271598.1111.78.camel@revolution.hippie.lan> <20130829192204.d97dcc714deb96ae5ace2b93@getmail.no> In-Reply-To: <20130829192204.d97dcc714deb96ae5ace2b93@getmail.no> 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 List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Aug 2013 20:39:29 -0000 On 08/30/2013 03:22, Torfinn Ingolfsen wrote: > On Thu, 29 Aug 2013 10:17:21 -0700 > Adrian Chadd wrote: > >> (top posting so one doesn't have to scroll down to the bottom to read >> this..) > > Everyone: it would be much easier if _everyone_ trimmed their quotes, instead of being lazy. +1! cheers, gja From owner-freebsd-arm@FreeBSD.ORG Fri Aug 30 00:38: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 142AB901; Fri, 30 Aug 2013 00:38:59 +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 BE16E2644; Fri, 30 Aug 2013 00:38:58 +0000 (UTC) Received: from wonderland.m5p.com (localhost [IPv6:::1]) by mailhost.m5p.com (8.14.5/8.14.5) with ESMTP id r7U0cmaA024641; Thu, 29 Aug 2013 20:38:54 -0400 (EDT) (envelope-from george+freebsd@m5p.com) Message-ID: <521FE998.6020402@m5p.com> Date: Thu, 29 Aug 2013 20:38:48 -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: Hans Petter Selasky Subject: Re: ulpt can't attach Lexmark E120 References: <5105527F.3010708@m5p.com> <201301271915.47712.hselasky@c2i.net> <510570C1.1060607@m5p.com> <201301272007.30682.hselasky@c2i.net> <5105AB16.2000607@m5p.com> <5215F4DF.6000305@m5p.com> <5215F743.8060403@bitfrost.no> <5216ACE5.7000500@m5p.com> <5216FE9F.2030608@bitfrost.no> <52174378.2020101@m5p.com> <521801E5.9000309@m5p.com> <52184F59.5080100@bitfrost.no> <5218F993.9050504@m5p.com> <5219C3FF.1070509@bitfrost.no> In-Reply-To: <5219C3FF.1070509@bitfrost.no> 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]); Thu, 29 Aug 2013 20:38:54 -0400 (EDT) Cc: freebsd-arm@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: Fri, 30 Aug 2013 00:38:59 -0000 On 08/25/13 04:44, Hans Petter Selasky wrote: > On 08/24/13 20:21, George Mitchell wrote: >> >> Setting hw.usb.dwc_otg.debug to any value greater than 0 generates an >> unending stream of debug output and effectively locks up the chip >> scrolling the output on the display. Perhaps there are some specific >> debug messages I could put in ... -- George > > Hi, > > Can you try this patch: > > http://svnweb.freebsd.org/changeset/base/254828 > > --HPS > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" Finally my RPi build system is working again and I can happily report that my Lexmark printer attaches successfully! Thank you! (And I note the patch has been checked into the repository.) -- George From owner-freebsd-arm@FreeBSD.ORG Fri Aug 30 00:43:32 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 6C250A8E; Fri, 30 Aug 2013 00:43:32 +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 1CE23269D; Fri, 30 Aug 2013 00:43:32 +0000 (UTC) Received: from wonderland.m5p.com (localhost [IPv6:::1]) by mailhost.m5p.com (8.14.5/8.14.5) with ESMTP id r7U0hP7i024675; Thu, 29 Aug 2013 20:43:30 -0400 (EDT) (envelope-from george+freebsd@m5p.com) Message-ID: <521FEAAD.6070901@m5p.com> Date: Thu, 29 Aug 2013 20:43:25 -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: Adrian Chadd Subject: Re: Reminder: Removal of WITHOUT_ARM_EABI References: <20130820091527.42127170@bender.Home> <1377271598.1111.78.camel@revolution.hippie.lan> <1377787319.1111.277.camel@revolution.hippie.lan> 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]); Thu, 29 Aug 2013 20:43:31 -0400 (EDT) Cc: "freebsd-arm@freebsd.org" , Ian Lepore , 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: Fri, 30 Aug 2013 00:43:32 -0000 On 08/29/13 12:10, Adrian Chadd wrote: > On 29 August 2013 07:41, Ian Lepore wrote: > [...] does someone have a known working > revision on any arm platform from April that is easy to just go kernel > commit revision bisecting with? > > > > -adrian > Oddly reminiscent of my recent question regarding a "pretty good" RPi build version. A build today from r254984 crashes doing an "ls" of an NFS-mounted file system: "Fatal kernel mode prefetch abort at 0x4278f502". No more details because I don't have a serial connection. Does WITHOUT_ARM_EABI go in /etc/src.conf if I want to try it out? -- George From owner-freebsd-arm@FreeBSD.ORG Fri Aug 30 01:06: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 749EAFAA; Fri, 30 Aug 2013 01:06:18 +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 46B8B27A8; Fri, 30 Aug 2013 01:06:18 +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 1VFDAF-00073k-JM; Fri, 30 Aug 2013 01:06:15 +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 r7U16Cwt056279; Thu, 29 Aug 2013 19:06:12 -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/45a6JwrFhFkhnym9wNwoI Subject: Re: Reminder: Removal of WITHOUT_ARM_EABI From: Ian Lepore To: George Mitchell In-Reply-To: <521FEAAD.6070901@m5p.com> References: <20130820091527.42127170@bender.Home> <1377271598.1111.78.camel@revolution.hippie.lan> <1377787319.1111.277.camel@revolution.hippie.lan> <521FEAAD.6070901@m5p.com> Content-Type: text/plain; charset="us-ascii" Date: Thu, 29 Aug 2013 19:06:11 -0600 Message-ID: <1377824771.1111.302.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: Fri, 30 Aug 2013 01:06:18 -0000 On Thu, 2013-08-29 at 20:43 -0400, George Mitchell wrote: > On 08/29/13 12:10, Adrian Chadd wrote: > > On 29 August 2013 07:41, Ian Lepore wrote: > > [...] does someone have a known working > > revision on any arm platform from April that is easy to just go kernel > > commit revision bisecting with? > > > > > > > > -adrian > > > Oddly reminiscent of my recent question regarding a "pretty good" RPi > build version. A build today from r254984 crashes doing an "ls" of an > NFS-mounted file system: "Fatal kernel mode prefetch abort at > 0x4278f502". No more details because I don't have a serial connection. > Does WITHOUT_ARM_EABI go in /etc/src.conf if I want to try it out? > -- George Put it in make.conf because you want the ABI to be in effect for everything you build, whether it's /usr/src or ports or whatever. In theory src.conf is only for stuff under /usr/src (although I think someone said recently it leaks into some ports builds). -- Ian From owner-freebsd-arm@FreeBSD.ORG Fri Aug 30 02:11:38 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 0B336691 for ; Fri, 30 Aug 2013 02:11:38 +0000 (UTC) (envelope-from ganbold@gmail.com) Received: from mail-pb0-x236.google.com (mail-pb0-x236.google.com [IPv6:2607:f8b0:400e:c01::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id D63702AF3 for ; Fri, 30 Aug 2013 02:11:37 +0000 (UTC) Received: by mail-pb0-f54.google.com with SMTP id ro12so1231489pbb.27 for ; Thu, 29 Aug 2013 19:11:37 -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=puyVBTbOh9Et+XHs4HjYwjzfHj8+MPDdFU5mTdK7tXo=; b=uEPrxeDHh5T07OUWOmIrn04abR5O4AwBYRgXS3SwIOguQuzHZXmFW+XXmcc2tg6pVV 042wVjQ/RGt0i4ItCxOeeXSXGX7EcYSoar5SNjbuEhcOBQXofDK1A3CijUKm2MiVN4I8 cJCSdKb6CkSSqr6l34HKc1utezuKIdWvUCcBc+7iqLSyokoVXgmfVFfuocBM9z5Z6ZEm YGgaFmvRSVUtnOk/Vrfwkz2TtrcWXYSgzHPpg/jqUimH9XmAvtoBrqwqIZBhPYKcGIdP s4N7Tg8g8GvxEBmKJI2/4fFl+IxUiUouuus5Qm2mz0MMiOralydYf5gv9BtvbnNd2lfv BTiA== MIME-Version: 1.0 X-Received: by 10.66.163.2 with SMTP id ye2mr7656318pab.168.1377828697071; Thu, 29 Aug 2013 19:11:37 -0700 (PDT) Received: by 10.68.88.129 with HTTP; Thu, 29 Aug 2013 19:11:36 -0700 (PDT) In-Reply-To: References: Date: Fri, 30 Aug 2013 10:11:36 +0800 Message-ID: Subject: Re: Booting kernel on Cubieboard/Mele a_1000 (Allwiner A10) From: Ganbold Tsagaankhuu To: Alexander Fedorov 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: Fri, 30 Aug 2013 02:11:38 -0000 Alexander, On Fri, Jun 28, 2013 at 2:51 AM, Alexander Fedorov < alexander.fedorov@rtlservice.com> wrote: > Hi! > Freebsd doesn't support Allwinner A10 MMC controller. > > You should use USB stick for the root filesystem. > > P.S. > I have an initial version of the driver for MMC, but it does not > support DMA, so the IO is very slow. I tested it with my Hackberry > board. > If you're interested, see the patch in attachment and configuration > files. Also, I will publish the code on github in a few days. > How reliable is this driver? Does it work well? If it is working well then maybe we should think about getting into src tree like fixing styles etc. Please let me know. Ganbold > > 2013/6/27 Mariano Lescano : > > Hi > > We have the kernel booting using ubldr. At the point to mount the root > > filesystem we get this message: > > > > ====================================================== > > > > Trying to mount root from ufs:/dev/mmcsd0s2a [rw,noatime]... > > stack_capture: frame=0xdcacfa3c > > stack_capture: frame=0 > > stack_capture: frame=0xdcacf85c > > stack_capture: frame=0xc30feda4 > > stack_capture: frame=0 > > mountroot: waiting for device /dev/mmcsd0s2a ... > > Mounting from ufs:/dev/mmcsd0s2a failed with error 19. > > Trying to mount root from ufs:/dev/da0s2a []... > > mountroot: waiting for device /dev/da0s2a ... > > Mounting from ufs:/dev/da0s2a failed with error 19. > > > > Loader variables: > > vfs.root.mountfrom=ufs:/dev/mmcsd0s2a > > vfs.root.mountfrom.options=rw,noatime > > > > Manual root filesystem specification: > > : [options] > > Mount using filesystem > > and with the specified (optional) option list. > > > > eg. ufs:/dev/da0s1a > > zfs:tank > > cd9660:/dev/acd0 ro > > (which is equivalent to: mount -t cd9660 -o ro /dev/acd0 /) > > > > ? List valid disk boot devices > > . Yield 1 second (for background tasks) > > Abort manual input > > > > mountroot> ? > > > > List of GEOM managed disk devices: > > > > > > mountroot> > > > > ======================================================== > > > > We can see that List of GEOM managed disk devices is empty > > > > What could be the problem? > > Any suggestions? > > > > Thanks > > _______________________________________________ > > 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 Fri Aug 30 11:24: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 AC940EFF for ; Fri, 30 Aug 2013 11:24:05 +0000 (UTC) (envelope-from bounces+8667-817c-freebsd-arm=freebsd.org@email.change.org) Received: from o2.email.change.org (o2.email.change.org [208.115.214.114]) by mx1.freebsd.org (Postfix) with SMTP id 596862C10 for ; Fri, 30 Aug 2013 11:24:05 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=change.org; h=from :reply-to:to:subject:mime-version:content-type :content-transfer-encoding; s=smtpapi; bh=5Wq6Yif+Vhvo0H+7qt/Hn/ J3ghA=; b=cJIPaIsgiIG2wKx8FgL2uoByuWnE0yVT059RfwdB84TLNkT/LyjNNh pRJTCyuxt4IBGrTHz3/p7RIzRNPFMbM8B5QkR8np3rQuDG/HDCnfeNpubI/v6sDm QgMKDMlHbcPuwyMFqQ51/uaLGAvLQV1YFrMd5sWSoqT0hkBoUyF8M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=change.org; h=from:reply-to :to:subject:mime-version:content-type:content-transfer-encoding; q=dns; s=smtpapi; b=j/jpy17iU1FS6jFQNReofgig2Jsv69v7UgKIzG9uD6i AORBskZFIP7nFn8TTiEvymoULh5Nu+NyPM3aJ+n2J1YrpCyeyk7wsulDTeR/R4A9 VpkLIMJX7ijVnGAPTwpnp6YEy+pyTVX2bb2cMrw4HWvVo+0Vo2fEwqDAZWZ+p5+I = Received: by with SMTP id mf98.29938.522080D46 Fri, 30 Aug 2013 11:24:04 +0000 (GMT) Received: from change.org (unknown [166.78.39.42]) by mi13 (SG) with ESMTP id 140cef73f24.521.1c317a for ; Fri, 30 Aug 2013 11:24:04 +0000 (UTC) Date: Fri, 30 Aug 2013 11:24:03 +0000 From: Nataraj S Narayan To: freebsd-arm@freebsd.org Message-ID: <522080d3cc389_5f37137e884967fe@448757-resque1.change.org.com.mail> Subject: =?UTF-8?Q?I_just_signed_=E2=80=9CSpeaker_of_the_Lok_Sabha_Shrimati?= =?UTF-8?Q?_Meira_Kumar:_Send_the_RTI_=28Amendment=29_Bill, _2013_to_a_Standi?= =?UTF-8?Q?ng_Committee/Select_Committee_=E2=80=9D?= Mime-Version: 1.0 X-SG-EID: t2fXfoZHCw6vGsGKHqKxJ/rV5oGMz4+ZVTdCT99I5wVyWL9rLVcJlrGsVDazyOJDl3/9yvJJZxgqGs+/CFUh2tR5FbLBWHEuerOPmuKeElULUJ++kqiEuSQ6uy4EqUK2JAa1FEGwOpttJrEedbB1yonzveQdMUtW65AWHwbF7Rg= X-SG-ID: mJfmtnDhlbXd9jBRnW0Uoy8GoLeQsEG7seT3fiWN5Ns= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Nataraj S Narayan List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Aug 2013 11:24:05 -0000 Hey, I just signed the petition "Speaker of the Lok Sabha Shrimati Meira Kumar: Send the RTI (Amendment) Bill, 2013 to a Standing Committee/Select Committee " and wanted to see if you could help by adding your name. Our goal is to reach 15,000 signatures and we need more support. You can read more and sign the petition here: https://www.change.org/petitions/speaker-of-the-lok-sabha-shrimati-meira-kumar-send-the-rti-amendment-bill-2013-to-a-standing-committee-select-committee?share_id=fCRbZYnLyz&utm_source=share_petition&utm_medium=email&utm_campaign=petition_invitation Thanks! Nataraj You're receiving this message because Nataraj S Narayan sent you an email through Change.org's petition sharing tool. Change.org has not stored your email address. If you believe you have received this message in error, respond directly to Nataraj S Narayan at natarajsn@gmail.com. From owner-freebsd-arm@FreeBSD.ORG Fri Aug 30 12:06: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 D65052A0 for ; Fri, 30 Aug 2013 12:06:00 +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 448A42ED9 for ; Fri, 30 Aug 2013 12:05:59 +0000 (UTC) Received: from cpsps-ews23.kpnxchange.com ([10.94.84.189]) by cpsmtpb-ews03.kpnxchange.com with Microsoft SMTPSVC(7.5.7601.17514); Fri, 30 Aug 2013 14:04:52 +0200 Received: from CPSMTPM-TLF103.kpnxchange.com ([195.121.3.6]) by cpsps-ews23.kpnxchange.com with Microsoft SMTPSVC(7.5.7601.17514); Fri, 30 Aug 2013 14:04:53 +0200 Received: from sjakie.klop.ws ([212.182.167.131]) by CPSMTPM-TLF103.kpnxchange.com with Microsoft SMTPSVC(7.5.7601.17514); Fri, 30 Aug 2013 14:04:52 +0200 Received: from 212-182-167-131.ip.telfort.nl (localhost [127.0.0.1]) by sjakie.klop.ws (Postfix) with ESMTP id D1907C628 for ; Fri, 30 Aug 2013 14:04:52 +0200 (CEST) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes To: freebsd-arm@freebsd.org Subject: Re: Reminder: Removal of WITHOUT_ARM_EABI References: <20130820091527.42127170@bender.Home> <1377271598.1111.78.camel@revolution.hippie.lan> <6046B66D-5F4C-4E8D-923A-3E26DED5DD8F@bsdimp.com> Date: Fri, 30 Aug 2013 14:04:52 +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: 30 Aug 2013 12:04:52.0827 (UTC) FILETIME=[22787AB0:01CEA579] 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, 30 Aug 2013 12:06:01 -0000 On Thu, 29 Aug 2013 19:38:44 +0200, Adrian Chadd wrote: > On 29 August 2013 10:25, Warner Losh wrote: > >> >> On Aug 29, 2013, at 11:17 AM, Adrian Chadd wrote: >> >> > (top posting so one doesn't have to scroll down to the bottom to read >> > this..) >> > >> > ARM people - is this useful? This looks to me like the serial console >> IO >> > path to enter ddb. I guess uart_bus_attach() is the wrong function >> name >> and >> > the real function is something inside the uart RX path >> >> This stack trace is poo. These routines long ago finished running, and >> certainly wouldn't be running in the context of df. > > > They'd be running if he hit the magic "please sir, may I enter ddb?" > routine. The attach function is just ddb getting the symbol lookup wrong > - > you'd have to run (arm) addr2line to get the PC -> symbol. > > But the wchan shows its running, not that it's spun in the kernel. So, > either it's running and doign ridiculous amounts of syscalls in some kind > of loop, or it's actually spinning in userland. > > Re jmg - yeah, maybe running it in userland gdb will shed more light. Hi, it is about the df in this line in /etc/rc.d/initrandom. ( kenv; dmesg; df -ib; ps -fauxww; date; sysctl -a ) \ | dd of=/dev/random bs=8k 2>/dev/null If I (only) remove the df it waits on the ps. If I remove the ps it waits on sysctl. Maybe interesting information. Because it is still running the boot scripts I don't know how to attach gdb. Any pointer how to do that? ... Oh wow, for some lucky reason I add rc_info="YES" to rc.conf and when I rebooted it did an fsck of all filesystems and it booted into multiuser. I am now logged in and see the same as Ian. Top does not work. Df hangs. Etc. I see I don't have debugging symbols compiled in the userland so I need to rebuild to make gdb happy. Ronald. From owner-freebsd-arm@FreeBSD.ORG Sat Aug 31 09:02:35 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 306C0517 for ; Sat, 31 Aug 2013 09:02:35 +0000 (UTC) (envelope-from mailinglists@martinlaabs.de) Received: from relay01.alfahosting-server.de (relay01.alfahosting-server.de [109.237.142.236]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id DD01F24A9 for ; Sat, 31 Aug 2013 09:02:34 +0000 (UTC) Received: by relay01.alfahosting-server.de (Postfix, from userid 1001) id DF53B32C4367; Sat, 31 Aug 2013 11:01:42 +0200 (CEST) X-Spam-DCC: : X-Spam-Level: X-Spam-Status: No, score=0.0 required=7.0 tests=BAYES_50 autolearn=disabled version=3.2.5 Received: from alfa3018.alfahosting-server.de (alfa3018.alfahosting-server.de [109.237.140.30]) by relay01.alfahosting-server.de (Postfix) with ESMTPS id 8E3E432C42EE for ; Sat, 31 Aug 2013 11:01:41 +0200 (CEST) Received: from [192.168.1.55] (p54B30D79.dip0.t-ipconnect.de [84.179.13.121]) by alfa3018.alfahosting-server.de (Postfix) with ESMTPSA id E48FF515DD04 for ; Sat, 31 Aug 2013 11:01:40 +0200 (CEST) Message-ID: <5221B0F2.9080905@martinlaabs.de> Date: Sat, 31 Aug 2013 11:01:38 +0200 From: Martin Laabs User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130809 Thunderbird/17.0.8 MIME-Version: 1.0 To: "freebsd-arm@freebsd.org" Subject: Rasperry Pi is stable Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Status: No X-Virus-Checker-Version: clamassassin 1.2.4 with ClamAV 0.97.3/17780/Sat Aug 31 06:44:32 2013 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Aug 2013 09:02:35 -0000 Hi, as you know there where problems with heavy load leads to a stall of the raspberry. I could not see this problem running r254984. I think the problem was the deadlock in the pmap system that was solved/rewinded before the networking issue made tests impossible. So I'm looking forward doing further tests. Best regards, Martin Laabs From owner-freebsd-arm@FreeBSD.ORG Sat Aug 31 09:40:39 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 D647BAE3 for ; Sat, 31 Aug 2013 09:40:39 +0000 (UTC) (envelope-from mattia.rossi.mate@gmail.com) Received: from mail-ea0-x229.google.com (mail-ea0-x229.google.com [IPv6:2a00:1450:4013:c01::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 58B692642 for ; Sat, 31 Aug 2013 09:40:39 +0000 (UTC) Received: by mail-ea0-f169.google.com with SMTP id k11so1355272eaj.14 for ; Sat, 31 Aug 2013 02:40:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=7S2q0F1NPRTzNx27McgmmEQyieSoT3kbXstfzeXjpAk=; b=LrF2/St/csUhsoZUPmmZLEt2k0OVYopRSA2NY/g/XaxvKCwUvJQAJC8ZNqU9RvTbN2 hdTmHG03d42UI4/ph5VRmyKXCRTjQ0KporXNcl6wM2DglsuGLeZl+JsA92sIsqG+Qtho RRMczHwR3VcXphOT3B8jgnoQp2qgD9zG0+EwB0jRG8d6PZds06H9HVlo5Vb3l3swTLq+ ufj0lVHeADK96uFXo/VTmf9UhXjqnJ/kS1YS07KMmswVwbg70wIwxszH3AsBPFAJad2R LVXMHQRth/Em0N7iZpSB5leEYrMm4NnuSf7E+WmHzmwEt4z7fyUgj7AMrEv63QMSApyf EK0A== X-Received: by 10.14.37.4 with SMTP id x4mr19785114eea.16.1377942037610; Sat, 31 Aug 2013 02:40:37 -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 x47sm3658505eea.16.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 31 Aug 2013 02:40:36 -0700 (PDT) Message-ID: <5221BA13.5040309@gmail.com> Date: Sat, 31 Aug 2013 11:40:35 +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 Subject: Alignment Fault 1 - still/again 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 List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Aug 2013 09:40:39 -0000 I've already posted my alignment issues once here, where I got stuck in something like this: mvsch1: at channel 1 on mvs0 cryptosoft0: Timecounters tick every 10.000 msec IPsec: Initialized Security Association Processing. ipfw2 (+ipv6) initialized, divert enabled, nat enabled, default to accept, loggd DUMMYNET 0 with IPv6 initialized (100409) load_dn_sched dn_sched FIFO loaded load_dn_sched dn_sched PRIO loaded load_dn_sched dn_sched QFQ loaded load_dn_sched dn_sched RR loaded load_dn_sched dn_sched WF2Q+ loaded Fatal kernel mode data abort: 'Alignment Fault 1' trapframe: 0xc0f1acf0 FSR=00000001, FAR=c0f1aed4, spsr=a00000d3 r0 =c0f05160, r1 =c3b4cc40, r2 =c0f1aebc, r3 =00000001 r4 =c0f05160, r5 =c3b4cc40, r6 =c0ef9244, r7 =c0f0b180 r8 =00000000, r9 =c0edf5f0, r10=00000104, r11=c0f1ad68 r12=00000000, ssp=c0f1ad40, slr=c0ad1690, pc =c0d9d8c4 [ thread pid 0 tid 100036 ] Stopped at cpu_switch+0x28: und 0xe1c281f8 db> I've managed to get around this for a while by adding options SCTP to the kernel. But then usually got stuck at "entropy harvesting", like Ian and Ronald. (See WITHOUT_ARM_EABI) thread. Compiling without EABI doesn't help anymore, as that only changes things for userspace, where I got a Signal 11 for init instead of getting stuck at entropy harvesting. Now I've updated to r255074M and options SCTP doesn't help anymore, and I'm stuck at the alignment failure above. So I activated witness and here's the output: ipfw2 (+ipv6) initialized, divert enabled, nat enabled, default to accept, loggd DUMMYNET 0 with IPv6 initialized (100409) load_dn_sched dn_sched FIFO loaded load_dn_sched dn_sched PRIO loaded load_dn_sched dn_sched QFQ loaded load_dn_sched dn_sched RR loaded load_dn_sched dn_sched WF2Q+ loaded lock order reversal: 1st 0xc1094e2c entropy harvest mutex (entropy harvest mutex) @ /usr/devel/drea2 2nd 0xc3896420 uart_hwmtx (uart_hwmtx) @ /usr/devel/dreamplug/sys/dev/uart/uar2 KDB: stack backtrace: db_trace_self() at db_trace_self pc = 0xc0d98464 lr = 0xc0943cf4 (X_db_symbol_values+0x11c) sp = 0xdcfb19c8 fp = 0xdcfb1ae0 r10 = 0xc1094e2c X_db_symbol_values() at X_db_symbol_values+0x11c pc = 0xc0943cf4 lr = 0xc0ae05c4 (kdb_backtrace+0x38) sp = 0xdcfb1ae8 fp = 0xdcfb1af0 r4 = 0xc0f2f274 r5 = 0xc0df4456 r6 = 0xc0dff4d1 r7 = 0xc0def19a kdb_backtrace() at kdb_backtrace+0x38 pc = 0xc0ae05c4 lr = 0xc0afaacc (witness_checkorder+0xddc) sp = 0xdcfb1af8 fp = 0xdcfb1b48 r4 = 0xc0df4335 witness_checkorder() at witness_checkorder+0xddc pc = 0xc0afaacc lr = 0xc0a9aa34 (__mtx_lock_spin_flags+0xc8) sp = 0xdcfb1b50 fp = 0xdcfb1b70 r4 = 0x00000000 r5 = 0xc0f16140 r6 = 0xc3896430 r7 = 0xc3896420 r8 = 0x00000000 r9 = 0xc0df4453 r10 = 0x0000005c __mtx_lock_spin_flags() at __mtx_lock_spin_flags+0xc8 pc = 0xc0a9aa34 lr = 0xc0994788 (uart_tty_detach+0x9c4) sp = 0xdcfb1b78 fp = 0xdcfb1b88 r4 = 0x0000006c r5 = 0xc0f1e694 r6 = 0xc0f2f270 r7 = 0xc0f1fb60 r8 = 0xc0ef1f80 r9 = 0xc0f1fb40 r10 = 0xdcfb1cf0 uart_tty_detach() at uart_tty_detach+0x9c4 pc = 0xc0994788 lr = 0xc0a689dc (cnputc+0x80) sp = 0xdcfb1b90 fp = 0xdcfb1ba8 r4 = 0x0000006c r5 = 0xc0ee26a0 r6 = 0xc0f2f270 cnputc() at cnputc+0x80 pc = 0xc0a689dc lr = 0xc0ae638c (kvprintf+0x128c) sp = 0xdcfb1bb0 fp = 0xdcfb1c18 r4 = 0x00000005 r5 = 0xdcfb1cf0 r6 = 0x0000006c r7 = 0x00000000 r8 = 0x00000000 r9 = 0xc0ae61f8 kvprintf() at kvprintf+0x128c pc = 0xc0ae638c lr = 0xc0ae51b4 (kvprintf+0xb4) sp = 0xdcfb1c20 fp = 0xdcfb1cd8 r4 = 0xc0e10430 r5 = 0x00000000 r6 = 0x00000000 r7 = 0x00000000 r8 = 0x00000000 r9 = 0xc0ae61f8 r10 = 0xdcfb1cf0 kvprintf() at kvprintf+0xb4 pc = 0xc0ae51b4 lr = 0xc0ae68f4 (printf+0x50) sp = 0xdcfb1ce0 fp = 0xdcfb1d10 r4 = 0xc36f2da8 r5 = 0xc36f2a68 r6 = 0x00000000 r7 = 0xc106230c r8 = 0xc1096524 r9 = 0x00000001 r10 = 0xc106231b printf() at printf+0x50 pc = 0xc0ae68f4 lr = 0xc0afa82c (witness_checkorder+0xb3c) sp = 0xdcfb1d28 fp = 0xdcfb1d78 witness_checkorder() at witness_checkorder+0xb3c pc = 0xc0afa82c lr = 0xc0a9aa34 (__mtx_lock_spin_flags+0xc8) sp = 0xdcfb1d80 fp = 0xdcfb1da0 r4 = 0x00000000 r5 = 0xc0f16140 r6 = 0xc0f2f634 r7 = 0xc0f2f624 r8 = 0x00000000 r9 = 0xc0e0e641 r10 = 0x000000f0 __mtx_lock_spin_flags() at __mtx_lock_spin_flags+0xc8 pc = 0xc0a9aa34 lr = 0xc0aece10 (sleepq_lock+0x30) sp = 0xdcfb1da8 fp = 0xdcfb1da8 r4 = 0xc383c320 r5 = 0xc0f1ded4 r6 = 0x00000000 r7 = 0x00000000 r8 = 0x00000000 r9 = 0xc0f16140 r10 = 0xc0f1ded0 sleepq_lock() at sleepq_lock+0x30 pc = 0xc0aece10 lr = 0xc0ab5dc0 (msleep_spin_sbt+0x84) sp = 0xdcfb1db0 fp = 0xdcfb1df0 msleep_spin_sbt() at msleep_spin_sbt+0x84 pc = 0xc0ab5dc0 lr = 0xc095e39c (random_yarrow_write+0x458) sp = 0xdcfb1df8 fp = 0xdcfb1e38 r4 = 0xc1094e3c r5 = 0x00000000 r6 = 0xc0def197 r7 = 0x00000000 r8 = 0x00000000 r9 = 0x00000000 r10 = 0xc0f1ded0 random_yarrow_write() at random_yarrow_write+0x458 pc = 0xc095e39c lr = 0xc0a802ac (fork_exit+0x84) sp = 0xdcfb1e40 fp = 0xdcfb1e58 r4 = 0xc383c320 r5 = 0xc383a320 r6 = 0xc095e12c r7 = 0xc0f16140 r8 = 0xdcfb1e60 r9 = 0x00000000 r10 = 0x00000000 fork_exit() at fork_exit+0x84 pc = 0xc0a802ac lr = 0xc0da85d4 (fork_trampoline+0x14) sp = 0xdcfb1e60 fp = 0x00000000 r4 = 0xc095e12c r5 = 0x00000000 r6 = 0x00000000 r7 = 0x00000000 r8 = 0x00000000 r9 = 0x00000000 fork_trampoline() at fork_trampoline+0x14 pc = 0xc0da85d4 lr = 0xc0da85d4 (fork_trampoline+0x14) sp = 0xdcfb1e60 fp = 0x00000000 Unable to unwind further KDB: enter: witness_checkorder [ thread pid 13 tid 100012 ] Stopped at kdb_enter+0x4c: ldrb r15, [r15, r15, ror r15]! db> Any hints? Cheers, Mat From owner-freebsd-arm@FreeBSD.ORG Sat Aug 31 13:12: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 CF400733 for ; Sat, 31 Aug 2013 13:12:23 +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 7DE5220EF for ; Sat, 31 Aug 2013 13:12:23 +0000 (UTC) Received: from wonderland.m5p.com (localhost [IPv6:::1]) by mailhost.m5p.com (8.14.5/8.14.5) with ESMTP id r7VDCGNO040551 for ; Sat, 31 Aug 2013 09:12:21 -0400 (EDT) (envelope-from george+freebsd@m5p.com) Message-ID: <5221EBB0.1030508@m5p.com> Date: Sat, 31 Aug 2013 09:12:16 -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: Rasperry Pi is stable References: <5221B0F2.9080905@martinlaabs.de> In-Reply-To: <5221B0F2.9080905@martinlaabs.de> Content-Type: multipart/mixed; boundary="------------090403090700060606080005" 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, 31 Aug 2013 09:12:21 -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, 31 Aug 2013 13:12:23 -0000 This is a multi-part message in MIME format. --------------090403090700060606080005 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 08/31/13 05:01, Martin Laabs wrote: > Hi, > > as you know there where problems with heavy load leads to a stall of the > raspberry. I could not see this problem running r254984. > I think the problem was the deadlock in the pmap system that was > solved/rewinded before the networking issue made tests impossible. > > So I'm looking forward doing further tests. > > Best regards, > Martin Laabs > > _______________________________________________ > 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" > That's the exact revision I tried earlier this week ... -- George --------------090403090700060606080005 Content-Type: message/rfc822; name="Attached Message" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Attached Message" X-Mozilla-Keys: Message-ID: <521FEAAD.6070901@m5p.com> Date: Thu, 29 Aug 2013 20:43:25 -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: Adrian Chadd CC: Ian Lepore , "freebsd-arm@freebsd.org" , Ronald Klop Subject: Re: Reminder: Removal of WITHOUT_ARM_EABI References: <20130820091527.42127170@bender.Home> <1377271598.1111.78.camel@revolution.hippie.lan> <1377787319.1111.277.camel@revolution.hippie.lan> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 08/29/13 12:10, Adrian Chadd wrote: > On 29 August 2013 07:41, Ian Lepore wrote: > [...] does someone have a known working > revision on any arm platform from April that is easy to just go kernel > commit revision bisecting with? > > > > -adrian > Oddly reminiscent of my recent question regarding a "pretty good" RPi build version. A build today from r254984 crashes doing an "ls" of an NFS-mounted file system: "Fatal kernel mode prefetch abort at 0x4278f502". No more details because I don't have a serial connection. Does WITHOUT_ARM_EABI go in /etc/src.conf if I want to try it out? -- George --------------090403090700060606080005-- From owner-freebsd-arm@FreeBSD.ORG Sat Aug 31 14:33: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 516D4243 for ; Sat, 31 Aug 2013 14:33:01 +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 289602511 for ; Sat, 31 Aug 2013 14:33:00 +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 1VFmEQ-000Btd-59; Sat, 31 Aug 2013 14:32:54 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id r7VEWolG065838; Sat, 31 Aug 2013 08:32:50 -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: U2FsdGVkX186/7TTg7IDeJJ+ih6MzdrO Subject: Re: Alignment Fault 1 - still/again From: Ian Lepore To: Mattia Rossi In-Reply-To: <5221BA13.5040309@gmail.com> References: <5221BA13.5040309@gmail.com> Content-Type: text/plain; charset="us-ascii" Date: Sat, 31 Aug 2013 08:32:50 -0600 Message-ID: <1377959570.1111.345.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-arm@FreeBSD.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Aug 2013 14:33:01 -0000 On Sat, 2013-08-31 at 11:40 +0200, Mattia Rossi wrote: > I've already posted my alignment issues once here, where I got stuck in > something like this: > > mvsch1: at channel 1 on mvs0 > cryptosoft0: > Timecounters tick every 10.000 msec > IPsec: Initialized Security Association Processing. > ipfw2 (+ipv6) initialized, divert enabled, nat enabled, default to > accept, loggd > DUMMYNET 0 with IPv6 initialized (100409) > load_dn_sched dn_sched FIFO loaded > load_dn_sched dn_sched PRIO loaded > load_dn_sched dn_sched QFQ loaded > load_dn_sched dn_sched RR loaded > load_dn_sched dn_sched WF2Q+ loaded > Fatal kernel mode data abort: 'Alignment Fault 1' > trapframe: 0xc0f1acf0 > FSR=00000001, FAR=c0f1aed4, spsr=a00000d3 > r0 =c0f05160, r1 =c3b4cc40, r2 =c0f1aebc, r3 =00000001 > r4 =c0f05160, r5 =c3b4cc40, r6 =c0ef9244, r7 =c0f0b180 > r8 =00000000, r9 =c0edf5f0, r10=00000104, r11=c0f1ad68 > r12=00000000, ssp=c0f1ad40, slr=c0ad1690, pc =c0d9d8c4 > > [ thread pid 0 tid 100036 ] > Stopped at cpu_switch+0x28: und 0xe1c281f8 > db> > > I've managed to get around this for a while by adding > > options SCTP > > to the kernel. But then usually got stuck at "entropy harvesting", like > Ian and Ronald. (See WITHOUT_ARM_EABI) thread. > Compiling without EABI doesn't help anymore, as that only changes things > for userspace, where I got a Signal 11 for init instead of getting stuck > at entropy harvesting. > > Now I've updated to r255074M and options SCTP doesn't help anymore, and > I'm stuck at the alignment failure above. > So I activated witness and here's the output: > > ipfw2 (+ipv6) initialized, divert enabled, nat enabled, default to > accept, loggd > DUMMYNET 0 with IPv6 initialized (100409) > load_dn_sched dn_sched FIFO loaded > load_dn_sched dn_sched PRIO loaded > load_dn_sched dn_sched QFQ loaded > load_dn_sched dn_sched RR loaded > load_dn_sched dn_sched WF2Q+ loaded > lock order reversal: > 1st 0xc1094e2c entropy harvest mutex (entropy harvest mutex) @ > /usr/devel/drea2 > 2nd 0xc3896420 uart_hwmtx (uart_hwmtx) @ > /usr/devel/dreamplug/sys/dev/uart/uar2 > KDB: stack backtrace: > [backtrace removed] > Unable to unwind further > KDB: enter: witness_checkorder > [ thread pid 13 tid 100012 ] > Stopped at kdb_enter+0x4c: ldrb r15, [r15, r15, ror r15]! > db> > > Any hints? > > Cheers, > > Mat That LOR is harmless (at least, I've been seeing it for a while). It's not correct that EABI only changes things for userspace -- quite the opposite, you can't run a mismatched kernel and userspace (as the init failure points out). I still can't get EABI to work on my dreamplug, every time I try I get more confusing symptoms (the latest -- trying to view a manpage gave a "too many symbols" error trying to launch man). -- Ian From owner-freebsd-arm@FreeBSD.ORG Sat Aug 31 14:43:54 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 6796938F; Sat, 31 Aug 2013 14:43:54 +0000 (UTC) (envelope-from mattia.rossi.mate@gmail.com) Received: from mail-ea0-x229.google.com (mail-ea0-x229.google.com [IPv6:2a00:1450:4013:c01::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id C76FF256B; Sat, 31 Aug 2013 14:43:53 +0000 (UTC) Received: by mail-ea0-f169.google.com with SMTP id k11so1461455eaj.28 for ; Sat, 31 Aug 2013 07:43:52 -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=UGLeDKWQ5sHsQYXmAW+HcidCxDA4ba9F38PeEP3kT9U=; b=aPkoZUOUHcw19+n4LUfKvSNvhr+f3AuS3+47N5hPMunz2gHS4uPtAI/ezOG9oDdjC6 Ba8Kqunp2TWNuNoyzwD5fNvJDSyMVb905fcuKale40pqC8uSjD+XLNHj+JD7xHyY3Neu UX1ewUEwTxe1aAi1GyRPP7YqyQrj2DKQkCLFJnwQs0v6dgH8lPRKHaCI8vXb4qx1xeJg 8aMk5KWT8rcCwdMZ4funQPFHvqhHdIRdmTnyuDG9lnFqnTobeX7swLhjXPmiEXUI8Trk IbpY9UBIl8EQP/ROPXKc4hljQ74mdTnSlBxwte6H/TsdMbJgOpTBSW3UXau4Y1pLJQBR efsQ== X-Received: by 10.14.108.9 with SMTP id p9mr21498306eeg.8.1377960232067; Sat, 31 Aug 2013 07:43:52 -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 d8sm5657229eeh.8.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 31 Aug 2013 07:43:51 -0700 (PDT) Message-ID: <52220126.8010607@gmail.com> Date: Sat, 31 Aug 2013 16:43:50 +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: Ian Lepore Subject: Re: Alignment Fault 1 - still/again References: <5221BA13.5040309@gmail.com> <1377959570.1111.345.camel@revolution.hippie.lan> In-Reply-To: <1377959570.1111.345.camel@revolution.hippie.lan> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-arm@FreeBSD.org 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: Sat, 31 Aug 2013 14:43:54 -0000 > That LOR is harmless (at least, I've been seeing it for a while). Ah, good... didn't even think i could simply continue... Well.. back being stuck at "entropy harvesting interrupts ethernet point_to_point" without being able to ^C > > It's not correct that EABI only changes things for userspace -- quite > the opposite, you can't run a mismatched kernel and userspace (as the > init failure points out). Sorry, what I meant was: for me it only gets stuck when running userspace tools. With or without EABI the kernel (now) loads fine) > > I still can't get EABI to work on my dreamplug, every time I try I get > more confusing symptoms (the latest -- trying to view a manpage gave a > "too many symbols" error trying to launch man). > > I never get beyond "entropy harvesting: interrupts ethernet point_to_point" :( Mat From owner-freebsd-arm@FreeBSD.ORG Sat Aug 31 14:47: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 999E24C2 for ; Sat, 31 Aug 2013 14:47:44 +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 6FFC52584 for ; Sat, 31 Aug 2013 14:47:44 +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 1VFmSl-0006EK-3V; Sat, 31 Aug 2013 14:47:43 +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 r7VElewg065852; Sat, 31 Aug 2013 08:47:40 -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: U2FsdGVkX196L54jZsii1H/060fMb3t7 Subject: Re: Alignment Fault 1 - still/again From: Ian Lepore To: mattia.rossi.mate@gmail.com In-Reply-To: <52220126.8010607@gmail.com> References: <5221BA13.5040309@gmail.com> <1377959570.1111.345.camel@revolution.hippie.lan> <52220126.8010607@gmail.com> Content-Type: text/plain; charset="us-ascii" Date: Sat, 31 Aug 2013 08:47:40 -0600 Message-ID: <1377960460.1111.347.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-arm@FreeBSD.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Aug 2013 14:47:44 -0000 On Sat, 2013-08-31 at 16:43 +0200, Mattia Rossi wrote: > > That LOR is harmless (at least, I've been seeing it for a while). > Ah, good... didn't even think i could simply continue... > Well.. back being stuck at "entropy harvesting interrupts ethernet > point_to_point" without being able to ^C > > > > It's not correct that EABI only changes things for userspace -- quite > > the opposite, you can't run a mismatched kernel and userspace (as the > > init failure points out). > Sorry, what I meant was: for me it only gets stuck when running > userspace tools. > With or without EABI the kernel (now) loads fine) > > > > I still can't get EABI to work on my dreamplug, every time I try I get > > more confusing symptoms (the latest -- trying to view a manpage gave a > > "too many symbols" error trying to launch man). > > > > > I never get beyond "entropy harvesting: interrupts ethernet point_to_point" > > :( That's a bit strange, that everyone can ^C out of that hang except you. You can get past it by editing /etc/rc.d/initrandom and commenting out the df and ps commands (just comment out all the initrandom kickstart stuff, it doesn't generate any real entropy anyway). -- Ian From owner-freebsd-arm@FreeBSD.ORG Sat Aug 31 17:37: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 813D1B82 for ; Sat, 31 Aug 2013 17:37:12 +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 3BBA62C8D for ; Sat, 31 Aug 2013 17:37:12 +0000 (UTC) Received: from wonderland.m5p.com (localhost [IPv6:::1]) by mailhost.m5p.com (8.14.5/8.14.5) with ESMTP id r7VHb4Sv042376 for ; Sat, 31 Aug 2013 13:37:09 -0400 (EDT) (envelope-from george+freebsd@m5p.com) Message-ID: <522229C0.5030504@m5p.com> Date: Sat, 31 Aug 2013 13:37:04 -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: What's the recipe? Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.73 on 10.100.0.3 X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.7 (mailhost.m5p.com [IPv6:::1]); Sat, 31 Aug 2013 13:37:09 -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, 31 Aug 2013 17:37:12 -0000 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? 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? 3. What svn version of /usr/src did you use in building the RPi image? 4. Did you use crochet? If so, what was the last commit in your git log? 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 From owner-freebsd-arm@FreeBSD.ORG Sat Aug 31 20:18:22 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 A26927B6 for ; Sat, 31 Aug 2013 20:18:22 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 76C7222C8 for ; Sat, 31 Aug 2013 20:18:22 +0000 (UTC) Received: by mail-pb0-f54.google.com with SMTP id ro12so3199612pbb.13 for ; Sat, 31 Aug 2013 13:18:16 -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=7D3q2nmJiAXjPbxVPUe4+B6gFV7PUuqKGVfu1BwwbPI=; b=EMBm2IAvXJud9bWxqS8deW8OzOnMrZvoueFypOouNWk3MG1aHxOj8/xQx5dCl5pAzR k8TjLMBH2eym9hMJqfqvT9rhUgBkqGHy/hSSGg3DrzP/AOyGdCxkPgo9xpjD6ud4skGg jqE0jqakYqetdhydHlS/60RioS3y1VNAxcYs9T0DDkf4rN5IhJfFdvd9P3Fey5kr+0Te YNbN3E3DAqAQovz+4SETuQZJQGGV8Ocq96MEqOWjY8x9OGOEM59qY04j4NfWiwJjGi2b +vcQr7md3WzCRz+4Hai7JFNOc2qpdVmeeRKS+e8O5f224yI8T+Zg4OWQxAz4Ohu/6URs LW5Q== X-Gm-Message-State: ALoCoQklcSQnx4YRs5IG6pF0tLXf3u9ve3tZZyilL3kfT4x4J7ur/2qCr+m1xClBhUjDQKOEZRLU X-Received: by 10.68.170.133 with SMTP id am5mr16919944pbc.104.1377980296525; Sat, 31 Aug 2013 13:18:16 -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 7sm6383152paf.22.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 31 Aug 2013 13:18:15 -0700 (PDT) Sender: Warner Losh Subject: Re: Alignment Fault 1 - still/again Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <1377960460.1111.347.camel@revolution.hippie.lan> Date: Sat, 31 Aug 2013 14:18:14 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5221BA13.5040309@gmail.com> <1377959570.1111.345.camel@revolution.hippie.lan> <52220126.8010607@gmail.com> <1377960460.1111.347.camel@revolution.hippie.lan> To: Ian Lepore X-Mailer: Apple Mail (2.1085) Cc: freebsd-arm@FreeBSD.org, mattia.rossi.mate@gmail.com 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, 31 Aug 2013 20:18:22 -0000 On Aug 31, 2013, at 8:47 AM, Ian Lepore wrote: > On Sat, 2013-08-31 at 16:43 +0200, Mattia Rossi wrote: >>> That LOR is harmless (at least, I've been seeing it for a while). >> Ah, good... didn't even think i could simply continue... >> Well.. back being stuck at "entropy harvesting interrupts ethernet=20 >> point_to_point" without being able to ^C >>>=20 >>> It's not correct that EABI only changes things for userspace -- = quite >>> the opposite, you can't run a mismatched kernel and userspace (as = the >>> init failure points out). >> Sorry, what I meant was: for me it only gets stuck when running=20 >> userspace tools. >> With or without EABI the kernel (now) loads fine) >>>=20 >>> I still can't get EABI to work on my dreamplug, every time I try I = get >>> more confusing symptoms (the latest -- trying to view a manpage = gave a >>> "too many symbols" error trying to launch man). >>>=20 >>>=20 >> I never get beyond "entropy harvesting: interrupts ethernet = point_to_point" >>=20 >> :( >=20 > That's a bit strange, that everyone can ^C out of that hang except = you. > You can get past it by editing /etc/rc.d/initrandom and commenting out > the df and ps commands (just comment out all the initrandom kickstart > stuff, it doesn't generate any real entropy anyway). Yea... Why are they hanging though? Warner= From owner-freebsd-arm@FreeBSD.ORG Sat Aug 31 21:09: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 E2C59E45; Sat, 31 Aug 2013 21:09:45 +0000 (UTC) (envelope-from mattia.rossi.mate@gmail.com) Received: from mail-ea0-x22d.google.com (mail-ea0-x22d.google.com [IPv6:2a00:1450:4013:c01::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 4ABC924AD; Sat, 31 Aug 2013 21:09:45 +0000 (UTC) Received: by mail-ea0-f173.google.com with SMTP id g10so1575738eak.32 for ; Sat, 31 Aug 2013 14:09: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=QPDOevJCDFvazdhQIK/XlCFN3J8EXjVzZS+rMech1NI=; b=oYF/h3LiBXBfhzVKg4e0bRRxPM3ePKGVWaR2h3KYxbuRHKeJgI7UEC6ieM/AxVuTj0 RolQIAeJuKCGopcH6sFNo6DB/CVt9oo1JpQAgVp9temnekoY6Oolak/bNUFO9/hZw8jm waursmHOfk01M2iVbwP9+tehKmD98ifsNjLWmiKYxvSJ66gIYeTKF9q4RNDoysn1ogSF gOaGZpkTCkytKgZwv9f1j4nAL41Z8tHTD+jFldilYXBJ7kMvVJns9m/TSV+QgGziO4ys Ud4R1VG1txYwdfvAFRs+UC+V1g1O598FQSXCBBRhRLq439Tsk9o3d62NSosGKU4mJ2QE wB9w== X-Received: by 10.15.45.8 with SMTP id a8mr23333445eew.1.1377983383576; Sat, 31 Aug 2013 14:09:43 -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 h52sm8097627eez.3.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 31 Aug 2013 14:09:42 -0700 (PDT) Message-ID: <52225B95.1020705@gmail.com> Date: Sat, 31 Aug 2013 23:09:41 +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: Warner Losh Subject: Re: Alignment Fault 1 - still/again References: <5221BA13.5040309@gmail.com> <1377959570.1111.345.camel@revolution.hippie.lan> <52220126.8010607@gmail.com> <1377960460.1111.347.camel@revolution.hippie.lan> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-arm@FreeBSD.org, Ian Lepore X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Aug 2013 21:09:46 -0000 On 31/08/13 22:18, Warner Losh wrote: > On Aug 31, 2013, at 8:47 AM, Ian Lepore wrote: > >> On Sat, 2013-08-31 at 16:43 +0200, Mattia Rossi wrote: >>>> That LOR is harmless (at least, I've been seeing it for a while). >>> Ah, good... didn't even think i could simply continue... >>> Well.. back being stuck at "entropy harvesting interrupts ethernet >>> point_to_point" without being able to ^C >>>> It's not correct that EABI only changes things for userspace -- quite >>>> the opposite, you can't run a mismatched kernel and userspace (as the >>>> init failure points out). >>> Sorry, what I meant was: for me it only gets stuck when running >>> userspace tools. >>> With or without EABI the kernel (now) loads fine) >>>> I still can't get EABI to work on my dreamplug, every time I try I get >>>> more confusing symptoms (the latest -- trying to view a manpage gave a >>>> "too many symbols" error trying to launch man). >>>> >>>> >>> I never get beyond "entropy harvesting: interrupts ethernet point_to_point" >>> >>> :( >> That's a bit strange, that everyone can ^C out of that hang except you. >> You can get past it by editing /etc/rc.d/initrandom and commenting out >> the df and ps commands (just comment out all the initrandom kickstart >> stuff, it doesn't generate any real entropy anyway). > > Yea... > > Why are they hanging though? After commenting better_than_nothing in etc/rc.d/initrandom it goes slightly further and then gets stuck again..: Entropy harvesting: interrupts ethernet point_to_point kickstart. Starting file system checks: /dev/da2s1: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/da2s1: clean, 373299 free (1475 frags, 46478 blocks, 0.0% fragmentation) Mounting local file systems:. Again no ^C to get out of that. As to why they're hanging.......... well I have ABSOLUTELY no clue. Mat