From owner-freebsd-arm@FreeBSD.ORG Sun Oct 4 22:28:22 2009 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A48F71065672 for ; Sun, 4 Oct 2009 22:28:22 +0000 (UTC) (envelope-from doginou@kanar.ci0.org) Received: from kanar.ci0.org (kanar.ci0.org [88.191.50.96]) by mx1.freebsd.org (Postfix) with ESMTP id 448F88FC0A for ; Sun, 4 Oct 2009 22:28:22 +0000 (UTC) Received: from kanar.ci0.org (pluxor@localhost [127.0.0.1]) by kanar.ci0.org (8.14.2/8.14.3) with ESMTP id n94MUZn2073151; Mon, 5 Oct 2009 00:30:35 +0200 (CEST) (envelope-from doginou@kanar.ci0.org) Received: (from doginou@localhost) by kanar.ci0.org (8.14.2/8.14.3/Submit) id n94MUZ5Q073150; Mon, 5 Oct 2009 00:30:35 +0200 (CEST) (envelope-from doginou) Date: Mon, 5 Oct 2009 00:30:35 +0200 From: Olivier Houchard To: Stanislav Sedov Message-ID: <20091004223035.GA72827@ci0.org> References: <4AC599FC.1070304@tomjudge.com> <20091002155600.2c2f615d.stas@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20091002155600.2c2f615d.stas@FreeBSD.org> User-Agent: Mutt/1.4.2.1i Cc: freebsd-arm@FreeBSD.org Subject: Re: [patch] Compilation problems in sys/arm/arm/pmap.c when PMAP_DEBUG is defined. X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 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, 04 Oct 2009 22:28:22 -0000 On Fri, Oct 02, 2009 at 03:56:00PM +0400, Stanislav Sedov wrote: > On Fri, 02 Oct 2009 06:13:16 +0000 > Tom Judge mentioned: > > > Hi, > > > > I ran into some issues this evening while I was building some kernels > > with PMAP_DEBUG defined. > > > > I have attached a patch that addresses the problems with the DPRINTF > > sections. (The first 2 hunks should probably be ignored). > > > > However there are 2 warnings about unused functions when PMAP_INLINE is > > defined as "". I did not know what the correct fix for this was so I > > defined PMAP_INLINE to __inline even when PMAP_DEBUG was set, which > > seemed to hide the problem again. > > > > Actually, these two functions with PMAP_INLINE prefixes are unused. I > believe we can drop them. > > Olivier, what do you think about the following patch? > Hi Stanislav, Removing pmap_use_l1() is fine, but please just comment pmap_dcache_wbinv_all() for now, and keep pmap_clean_page(), it's here to remember we still write back/invalidate the whole cache in pmap_copy_page() which is suboptimal. Regards, Olivier From owner-freebsd-arm@FreeBSD.ORG Mon Oct 5 11:06:48 2009 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7D99D1065754 for ; Mon, 5 Oct 2009 11:06:48 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 6B8738FC0C for ; Mon, 5 Oct 2009 11:06:48 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n95B6mHs088609 for ; Mon, 5 Oct 2009 11:06:48 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n95B6l6l088607 for freebsd-arm@FreeBSD.org; Mon, 5 Oct 2009 11:06:47 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 5 Oct 2009 11:06:47 GMT Message-Id: <200910051106.n95B6l6l088607@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 Cc: Subject: Current problem reports assigned to freebsd-arm@FreeBSD.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 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, 05 Oct 2009 11:06:48 -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/134368 arm [patch] nslu2_led driver for the LEDs on the NSLU2 o arm/134338 arm [patch] Lock GPIO accesses on ixp425 o arm/134092 arm [patch] NSLU.hints contains wrong hints for on board n 3 problems total. From owner-freebsd-arm@FreeBSD.ORG Tue Oct 6 03:50:26 2009 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C185D1065693 for ; Tue, 6 Oct 2009 03:50:26 +0000 (UTC) (envelope-from www@redwood.invision.net) Received: from redwood.invision.net (redwood.invision.net [69.18.154.217]) by mx1.freebsd.org (Postfix) with ESMTP id 096978FC1E for ; Tue, 6 Oct 2009 03:50:25 +0000 (UTC) Received: from redwood.invision.net (localhost [127.0.0.1]) by redwood.invision.net (8.13.6/8.13.6) with ESMTP id n962qOKt032097 for ; Mon, 5 Oct 2009 22:52:24 -0400 (EDT) (envelope-from www@redwood.invision.net) Received: (from www@localhost) by redwood.invision.net (8.13.6/8.13.6/Submit) id n962qOGx032096; Mon, 5 Oct 2009 22:52:24 -0400 (EDT) (envelope-from www) Date: Mon, 5 Oct 2009 22:52:24 -0400 (EDT) Message-Id: <200910060252.n962qOGx032096@redwood.invision.net> To: freebsd-arm@freebsd.org From: Kelly Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Content-Type: text/plain X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Quer me conhecer ? X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 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, 06 Oct 2009 03:50:26 -0000 #[1]ICRA labels [2]Swingers, Chat Adulto Gratuito & Site de Relacionamento Adulto - Adult FriendFinder Swingers, Chat Adulto Gratuito & Site de Relacionamento Adulto [glean.gif?rand=6127&site=ffadult&session=GNAbECd%40K%3B%3Eh+124593067 2+189.31.62.94+&pwsid=&pagename=ttp%3A%2F%2Fwww.google.com.br%2Fsearch &pagestate=&country=Brazil&city=&lang=portuguese&level=&gpid=g314429&p id=g314429.subgoogle4] [3]Conheça uma parceira sexual ou outros swingers como ela hoje à noite e participe Adult FriendFinder. Olhe sua fonte final para Rede Social Adulta, Sensual Namoros e Sexo Pessoal. [4]Encontre sócios reais de sexo está noite! Junta-se ao Adult FriendFinder, a maior rede de encontros sociais do mundo, Sexy Encontros e Sexy Pessoas, gratuito com mais de 20 milhões de usuários. [5]Quer encontrar uma parceira sexual como ela hoje à noite? Junte-se à Adult FriendFinder e navegue gratuitamente e encontre aquela compatibilidade excitada para você! References Visible links 1. http://graphics.pop6.com/images/ICRA_labels_rdf_adult.rdf 2. http://adultfriendfinder.com/go/g1114408 3. http://adultfriendfinder.com/go/g1114408 4. http://adultfriendfinder.com/go/g1114408 5. http://adultfriendfinder.com/go/g1114408 Hidden links: 6. http://adultfriendfinder.com/p/register.cgi?who=UmFuZG9tSVYUpehifN_D7VR_QVUJhm03H9VYqf/SWm4B3Z53sbIy7YIP/gbo2jcwKyJkLdHRy5BC1OkN6e5tfFR0sbFpAFZB0bQ5IRrl0uhTpA5Ox4O6LaMq8UA2akqTHYSkAwny9YGQTZcSFwtRsP24v30Iz6H_9RfhQXiCUyJCqvLnofBNWc67Wa1IHcTv3Shd4y1lq/Kl8FwJ79/dcBV1Ka2rV_cjKpodVxU6iP4-&site=ffadult From owner-freebsd-arm@FreeBSD.ORG Tue Oct 6 10:30:01 2009 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AF21D106566B for ; Tue, 6 Oct 2009 10:30:01 +0000 (UTC) (envelope-from franson@gmail.com) Received: from mail-iw0-f190.google.com (mail-iw0-f190.google.com [209.85.223.190]) by mx1.freebsd.org (Postfix) with ESMTP id 7394D8FC17 for ; Tue, 6 Oct 2009 10:30:01 +0000 (UTC) Received: by iwn28 with SMTP id 28so943962iwn.3 for ; Tue, 06 Oct 2009 03:30:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=SPtik7PojE2dY6BFbiNyiIZEVm8WwqI4CEwQKCi/oy4=; b=pyaKi568uPyafZPGDWLSsPs8v28TTe2FacE122JKcCis/5mFs28GioCjt8yA+3+2h4 am2IvZ9i7N/SHZvq4iA0jn5KpBvpL+HL2nuG2MOGo/rliHhaO21IopfxzNrDEJ/6gCyA EacEHRe3y3gd2FYVD4ekxARy+G7AK4rSzHUZA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type; b=OrePblI14EfbeEZLjNwoLIk7xOGY538xfe16f94nc+GXkszukEK/yYUwgMeTIuuLPl 0YraLb9c/NT3IiH81+AH5dXaKZaeOLuIPWGUGPMh3ZWp8qpuK4f88k9z8ZfhwZ2qf92m KX2MSWXnZYZiqXThJX8+nex17zEQT3r6jfjE0= MIME-Version: 1.0 Sender: franson@gmail.com Received: by 10.231.25.29 with SMTP id x29mr2335678ibb.31.1254823158251; Tue, 06 Oct 2009 02:59:18 -0700 (PDT) Date: Tue, 6 Oct 2009 17:59:18 +0800 X-Google-Sender-Auth: 2a58d58583518320 Message-ID: From: quickembed To: freebsd-arm@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: friendly arm board X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 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, 06 Oct 2009 10:30:01 -0000 find types of ARM board here: http://www.quickembed.com/Tools/Shop/ARM/Index.html They provide linux support, like mini 2440 and it is said that also android is supported by 6410 now! From owner-freebsd-arm@FreeBSD.ORG Tue Oct 6 15:41:24 2009 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 797BA106568D for ; Tue, 6 Oct 2009 15:41:24 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Received: from raven.bwct.de (raven.bwct.de [85.159.14.73]) by mx1.freebsd.org (Postfix) with ESMTP id 02EBB8FC0C for ; Tue, 6 Oct 2009 15:41:23 +0000 (UTC) Received: from cicely5.cicely.de ([10.1.1.7]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id n96FfLoh035630 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 6 Oct 2009 17:41:22 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (cicely7.cicely.de [10.1.1.9]) by cicely5.cicely.de (8.14.2/8.14.2) with ESMTP id n96FfII5071901 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 6 Oct 2009 17:41:18 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (localhost [127.0.0.1]) by cicely7.cicely.de (8.14.2/8.14.2) with ESMTP id n96FfIHO032426; Tue, 6 Oct 2009 17:41:18 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: (from ticso@localhost) by cicely7.cicely.de (8.14.2/8.14.2/Submit) id n96FfIrH032425; Tue, 6 Oct 2009 17:41:18 +0200 (CEST) (envelope-from ticso) Date: Tue, 6 Oct 2009 17:41:18 +0200 From: Bernd Walter To: quickembed Message-ID: <20091006154118.GE27530@cicely7.cicely.de> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: FreeBSD cicely7.cicely.de 7.0-STABLE i386 User-Agent: Mutt/1.5.11 X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED=-1.8, AWL=0.015, BAYES_00=-2.599 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on spamd.cicely.de Cc: freebsd-arm@freebsd.org Subject: Re: friendly arm board X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ticso@cicely.de List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Oct 2009 15:41:24 -0000 On Tue, Oct 06, 2009 at 05:59:18PM +0800, quickembed wrote: > find types of ARM board here: > http://www.quickembed.com/Tools/Shop/ARM/Index.html > They provide linux support, like mini 2440 and it is said that also > android is supported by 6410 now! "They"? You mean "You", at least your sender address makes it obvious. I don't think many people on this list have problems with vendors presenting their products, but it is better to play with open cards. Of course it would also be better to know something about FreeBSD support, since this is what this list is about - Linux is nice, but this is a FreeBSD list and FreeBSD-friendliness is what people prefer to read here. -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From owner-freebsd-arm@FreeBSD.ORG Tue Oct 6 16:56:51 2009 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7219C106566B for ; Tue, 6 Oct 2009 16:56:51 +0000 (UTC) (envelope-from franson@gmail.com) Received: from mail-iw0-f190.google.com (mail-iw0-f190.google.com [209.85.223.190]) by mx1.freebsd.org (Postfix) with ESMTP id 39E738FC08 for ; Tue, 6 Oct 2009 16:56:50 +0000 (UTC) Received: by iwn28 with SMTP id 28so1106274iwn.3 for ; Tue, 06 Oct 2009 09:56:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type; bh=yvTPdf90bbGELCZqSxFeTPrwdhg3jLtgX38XhjRqlDg=; b=r9OhMRGb61hubDfSXlfD5lxqukF9l/AUVRNIv8vz9yZUhpaqlFFYWXPGqqm5YayO1e L6GSCe8wFWXJoNE8P7CwTGQ8zIOz0R/r6jDIGDrBQUfpSh8xxjTgxK7bMhUfodWJlKyX ZxpqrMTRAZFlOJhD7NUj+/MXHXc6ajiUhirkM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=APciJBBdNM2b7Ue807SUZ9n2TxnOD/+ViplHDNtv0k/bndKH5YfPAsrmmZeAYYEd8g PPF9veKjMUZzCjdJM4roVw2sF9pqXduShOwUuPZjjZdsXR0CJ41AvInaKy5Z+DTUJHCi LZaOBd8iL4AYHvltMsR8iPynn97Fov54avihw= MIME-Version: 1.0 Sender: franson@gmail.com Received: by 10.231.5.90 with SMTP id 26mr3111330ibu.42.1254848210522; Tue, 06 Oct 2009 09:56:50 -0700 (PDT) In-Reply-To: <20091006154118.GE27530@cicely7.cicely.de> References: <20091006154118.GE27530@cicely7.cicely.de> Date: Wed, 7 Oct 2009 00:56:50 +0800 X-Google-Sender-Auth: 45d0019c5c402320 Message-ID: From: quickembed To: ticso@cicely.de Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-arm@freebsd.org Subject: Re: friendly arm board X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 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, 06 Oct 2009 16:56:51 -0000 You are right and I only want to bring some information here to you all, if someone has interest of porting FreeBSD to the ARM9 platforms, that will be great. I do find someone talked about working on FreeBSP on similar ARM platforms, that is the reason I posted here. Thanks for your kind notice. On Tue, Oct 6, 2009 at 11:41 PM, Bernd Walter wrote: > On Tue, Oct 06, 2009 at 05:59:18PM +0800, quickembed wrote: >> find types of ARM board here: >> http://www.quickembed.com/Tools/Shop/ARM/Index.html >> They provide linux support, like mini 2440 and it is said that also >> android is supported by 6410 now! > > "They"? > You mean "You", at least your sender address makes it obvious. > > I don't think many people on this list have problems with vendors > presenting their products, but it is better to play with open cards. > Of course it would also be better to know something about FreeBSD > support, since this is what this list is about - Linux is nice, but > this is a FreeBSD list and FreeBSD-friendliness is what people prefer > to read here. > > -- > B.Walter http://www.bwct.de > Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. > From owner-freebsd-arm@FreeBSD.ORG Tue Oct 6 17:10:22 2009 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 14CD41065676 for ; Tue, 6 Oct 2009 17:10:22 +0000 (UTC) (envelope-from stas@FreeBSD.org) Received: from mx0.deglitch.com (backbone.deglitch.com [IPv6:2001:16d8:fffb:4::abba]) by mx1.freebsd.org (Postfix) with ESMTP id B329D8FC08 for ; Tue, 6 Oct 2009 17:10:21 +0000 (UTC) Received: from stasss.yandex.ru (dhcp170-227-red.yandex.net [95.108.170.227]) by mx0.deglitch.com (Postfix) with ESMTPSA id 6D73F8FC4F; Tue, 6 Oct 2009 21:10:20 +0400 (MSD) Date: Tue, 6 Oct 2009 21:10:19 +0400 From: Stanislav Sedov To: quickembed Message-Id: <20091006211019.d26c6f7c.stas@FreeBSD.org> In-Reply-To: References: <20091006154118.GE27530@cicely7.cicely.de> Organization: The FreeBSD Project X-Mailer: carrier-pigeon Mime-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="PGP-SHA1"; boundary="Signature=_Tue__6_Oct_2009_21_10_19_+0400_4BVie2ZxtMNdvHUg" Cc: freebsd-arm@freebsd.org, ticso@cicely.de Subject: Re: friendly arm board X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 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, 06 Oct 2009 17:10:22 -0000 --Signature=_Tue__6_Oct_2009_21_10_19_+0400_4BVie2ZxtMNdvHUg Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, 7 Oct 2009 00:56:50 +0800 quickembed mentioned: > You are right and I only want to bring some information here to you > all, if someone has interest of porting FreeBSD to the ARM9 platforms, > that will be great. > I do find someone talked about working on FreeBSP on similar ARM > platforms, that is the reason I posted here. > Thanks for your kind notice. >=20 It'd be great if this company could provide some sample boards to the FreeBSD Foundation so developers can work on bringing them up with FreeBSD. In any case thank for information on this boards, but I think this is unappropriate list for this kind of information. Maybe freebsd-misc list or FreeBSD forums will fit better. Best regards, --=20 Stanislav Sedov ST4096-RIPE --Signature=_Tue__6_Oct_2009_21_10_19_+0400_4BVie2ZxtMNdvHUg Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- iQIcBAEBAgAGBQJKy3n7AAoJEKN82nOYvCd0UyQP/13QKzQXJZ/Kv70jbCmfcE0u vVSqW33sDtACjdIdpTqEkfODyBToU4M41pndzrMjHc+XZ5dTphze+3qKHN0APshq fseh7+JxQjVU8PBlwfgPTGJL+ueIf3OF6fv4ztIsY/NqPinlf1JLAfkwr1OOgOLl /faSnafWaqO3PKqwl2BaQFBjUygmTQuyOvHNJuMFjj5a0Goe3UX+8RGAU81f170c P7cTMKzCTKZs4VNkP9ZO8WWYeI1fJsUzjsGp45lpjE+KUVU7n0fLUzloK723x/2M 48TLIKQGvv5k/+IQAbofzBIpFRHUJJLv8uNMViEYhhYy6OINtN0fEUNDDyNVRdIJ B05hNTTHVs64QRvQO4YkhYjgzYw6T5DxVIItyW4PeCFoQxwYPgl8ajl745SUmtrB BcdmsEg7u/UHT90iLEASQBNeqvJpweTwQUw19Y2UGFg3045XUSi4kHYseWMWuHzH HAsyK/zGxa8FqBsP0Bqb61dKIUE5UCm7sfXUk4HQ0kJHSEEPe7/Q7zxsQPh8ixRS a4GsQDzKOIv19gDUoZsuzzSe8ks0JHa8muPp+DlvUfKtf3D36mkDUm/kXZi5j9GA uPARnBoHaGS0UZEMTJGXk71oiC+0+zosZpijUoam45l+c0rBJEfIvv5ydEAAVEdD Y+dXEpeBbAgRvEjKuMJw =1zwp -----END PGP SIGNATURE----- --Signature=_Tue__6_Oct_2009_21_10_19_+0400_4BVie2ZxtMNdvHUg-- From owner-freebsd-arm@FreeBSD.ORG Tue Oct 6 20:55:48 2009 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5A562106568D for ; Tue, 6 Oct 2009 20:55:48 +0000 (UTC) (envelope-from andrew@fubar.geek.nz) Received: from farnsworth.fubar.geek.nz (farnsworth.fubar.geek.nz [69.55.236.47]) by mx1.freebsd.org (Postfix) with ESMTP id 3E6C08FC26 for ; Tue, 6 Oct 2009 20:55:48 +0000 (UTC) Received: by farnsworth.fubar.geek.nz (Postfix, from userid 65534) id B239233C18; Tue, 6 Oct 2009 13:55:47 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on farnsworth.fubar.geek.nz X-Spam-Level: *** X-Spam-Status: No, score=3.0 required=5.0 tests=AWL,BAYES_00,HELO_LOCALHOST, RCVD_IN_PBL,RCVD_IN_SORBS_DUL autolearn=no version=3.2.5 Received: from localhost (217.27.255.123.static.snap.net.nz [123.255.27.217]) by farnsworth.fubar.geek.nz (Postfix) with ESMTP id DEA7433C13; Tue, 6 Oct 2009 13:55:45 -0700 (PDT) Date: Wed, 7 Oct 2009 09:55:50 +1300 From: Andrew Turner To: quickembed Message-ID: <20091007095550.5cec1f93@fubar.geek.nz> In-Reply-To: References: X-Mailer: Claws Mail 3.7.2 (GTK+ 2.16.6; amd64-portbld-freebsd7.2) X-Pirate: Arrrr Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-arm@freebsd.org Subject: Re: friendly arm board X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 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, 06 Oct 2009 20:55:48 -0000 On Tue, 6 Oct 2009 17:59:18 +0800 quickembed wrote: > find types of ARM board here: > http://www.quickembed.com/Tools/Shop/ARM/Index.html > They provide linux support, like mini 2440 and it is said that also > android is supported by 6410 now! I have a mini2440 sitting on my desk that I have had running FreeBSD to single-user mode. I'm unable to boot FreeBSD with USB support on it though so I haven't managed multi-user mode. As far as I know there is nobody working on S3C6410 support. I don't know how similar the peripherals on the chip are to the S3C24x0 chips to know how difficult it would be to port FreeBSD to it. Andrew From owner-freebsd-arm@FreeBSD.ORG Wed Oct 7 09:15:36 2009 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D286C106568B; Wed, 7 Oct 2009 09:15:36 +0000 (UTC) (envelope-from ray@ddteam.net) Received: from mail-bw0-f227.google.com (mail-bw0-f227.google.com [209.85.218.227]) by mx1.freebsd.org (Postfix) with ESMTP id 21B648FC1C; Wed, 7 Oct 2009 09:15:35 +0000 (UTC) Received: by bwz27 with SMTP id 27so3685248bwz.43 for ; Wed, 07 Oct 2009 02:15:34 -0700 (PDT) Received: by 10.103.81.38 with SMTP id i38mr1218571mul.92.1254905208264; Wed, 07 Oct 2009 01:46:48 -0700 (PDT) Received: from terran.mk.farlep.net (i168-101-19-89.vpdn.way.kv.chereda.net [89.19.101.168]) by mx.google.com with ESMTPS id 25sm2494473mul.55.2009.10.07.01.46.45 (version=SSLv3 cipher=RC4-MD5); Wed, 07 Oct 2009 01:46:46 -0700 (PDT) Sender: Alex RAY Date: Wed, 7 Oct 2009 11:46:12 +0300 From: Alexandr Rybalko To: Marcel Moolenaar Message-Id: <20091007114612.00408f53.ray@dlink.ua> In-Reply-To: <9BAB53FC-022B-4AA8-B29A-4B7428B5CC74@mac.com> References: <9BAB53FC-022B-4AA8-B29A-4B7428B5CC74@mac.com> Organization: D-Link X-Mailer: Sylpheed 2.6.0 (GTK+ 2.14.7; i386-portbld-freebsd7.1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: arm@freebsd.org, FreeBSD current mailing list Subject: Re: [ARM+NFS] panic while copying across NFS X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 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, 07 Oct 2009 09:15:36 -0000 Hi All! Testing on Orion like board (D-Link DNS-323) I get same result, panic on copy file across NFS. panic: vm_page_insert: offset already allocated backtrace - same. On Fri, 12 Jun 2009 13:19:22 -0700 Marcel Moolenaar wrote: >> I just ran into the following panic: >> >> panic: vm_page_insert: offset already allocated >> >> I was copying a kernel across NFS at the time: >> >> orion% cd /nfs/netboot/arm >> orion% ls >> kernel-save.bin kernel.bin ubldr >> orion% sudo cp kernel.bin kernel-save.bin >> orion% sudo cp /usr/obj/nfs/freebsd/base/head/sys/ORION/kernel.bin >> kernel.bin >> >> (/usr/obj is on a local disk) >> >> With this backtrace: >> >> db> bt >> Tracing pid 26585 tid 100073 td 0xc22bd6f0 >> db_trace_thread() at db_trace_thread+0x10 >> scp=0xc0ae66e8 rlv=0xc0914d78 (db_command_init+0x484) >> rsp=0xc8492878 rfp=0xc8492898 >> r10=0x00000001 r9=0xc0bb3e94 >> r8=0xc0babdc8 r7=0xc0bab59c r6=0x00000010 r5=0x00000000 >> r4=0xc22bd6f0 >> db_command_init() at db_command_init+0x404 >> scp=0xc0914cf8 rlv=0xc09145b4 (db_skip_to_eol+0x38c) >> rsp=0xc849289c rfp=0xc8492940 >> r6=0x00000002 r5=0x00000000 >> r4=0xc0b8bb80 >> db_skip_to_eol() at db_skip_to_eol+0x1d0 >> scp=0xc09143f8 rlv=0xc09147d0 (db_command_loop+0x50) >> rsp=0xc8492944 rfp=0xc8492954 >> r10=0x00000001 r8=0x00000000 >> r7=0xc8492b1c r6=0xc0bb3e90 r5=0x00000000 r4=0xc0bab598 >> db_command_loop() at db_command_loop+0x18 >> scp=0xc0914798 rlv=0xc0916960 (X_db_sym_numargs+0xa0) >> rsp=0xc8492958 rfp=0xc8492a74 >> r4=0xc849295c >> X_db_sym_numargs() at X_db_sym_numargs+0x18 >> scp=0xc09168d8 rlv=0xc09bcb98 (kdb_trap+0xb0) >> rsp=0xc8492a78 rfp=0xc8492aa0 >> r4=0x000000c0 >> kdb_trap() at kdb_trap+0x10 >> scp=0xc09bcaf8 rlv=0xc0af76cc (undefinedinstruction+0x124) >> rsp=0xc8492aa4 rfp=0xc8492b18 >> r10=0xc22bd6f0 r9=0x00000000 >> r8=0xc09bc88c r7=0xe7ffffff r6=0xc8492b1c r5=0x00000000 >> r4=0x00000000 >> undefinedinstruction() at undefinedinstruction+0x10 >> scp=0xc0af75b8 rlv=0xc0ae8174 (address_exception_entry+0x50) >> rsp=0xc8492b1c rfp=0xc8492b7c >> r10=0xc0d147c8 r8=0x00000000 >> r7=0xc22bd6f0 r6=0xc0bb00c0 r5=0xffff1004 r4=0x00000000 >> kdb_enter() at kdb_enter+0x14 >> scp=0xc09bc858 rlv=0xc09955f4 (panic+0xa0) >> rsp=0xc8492b80 rfp=0xc8492b94 >> r5=0xc0b4c994 r4=0x00000100 >> panic() at panic+0x1c >> scp=0xc0995570 rlv=0xc0ad8de0 (vm_page_insert+0x164) >> rsp=0xc8492ba8 rfp=0xc8492bc8 >> vm_page_insert() at vm_page_insert+0x10 >> scp=0xc0ad8c8c rlv=0xc0ad90f4 (vm_page_alloc+0x304) >> rsp=0xc8492bcc rfp=0xc8492bf4 >> r8=0x00001e03 r7=0x00000061 >> r6=0x00000001 r5=0xc0fe25c8 r4=0x00000000 >> vm_page_alloc() at vm_page_alloc+0x10 >> scp=0xc0ad8e00 rlv=0xc0acd740 (kmem_malloc+0x2b4) >> rsp=0xc8492bf8 rfp=0xc8492c48 >> r10=0x00000000 r9=0x00001000 >> r8=0x00000103 r7=0xc0e3a088 r6=0x01e03000 r5=0x00000061 >> r4=0xc1e03000 >> kmem_malloc() at kmem_malloc+0x14 >> scp=0xc0acd4a0 rlv=0xc0ac77bc (uma_zcreate+0xd0) >> rsp=0xc8492c4c rfp=0xc8492c88 >> r10=0xc0ac5efc r9=0xc0e36640 >> r8=0x00000103 r7=0xc1dfd000 r6=0xc1dfd000 r5=0x00000003 >> r4=0xc0e2d280 >> uma_zcreate() at uma_zcreate+0x70 >> scp=0xc0ac775c rlv=0xc0ac7d28 (uma_prealloc+0x198) >> rsp=0xc8492c8c rfp=0xc8492cac >> r10=0xc0e319d8 r9=0x00000020 >> r8=0xc0e36640 r7=0x00000000 r6=0xc0e36640 r5=0x00000203 >> r4=0xc0e2d280 >> uma_prealloc() at uma_prealloc+0xd4 >> scp=0xc0ac7c64 rlv=0xc0ac7fe8 (uma_prealloc+0x458) >> rsp=0xc8492cb0 rfp=0xc8492cc8 >> r7=0x00000002 r6=0xc0e36640 >> r5=0x00000003 r4=0xc0e2d280 >> uma_prealloc() at uma_prealloc+0x42c >> scp=0xc0ac7fbc rlv=0xc0ac9230 (uma_zalloc_arg+0x32c) >> rsp=0xc8492ccc rfp=0xc8492d10 >> r6=0xc1a5dcc0 r5=0x00000013 >> r4=0x00000013 >> uma_zalloc_arg() at uma_zalloc_arg+0x10 >> scp=0xc0ac8f14 rlv=0xc0a86710 (nfsm_uiotombuf+0xec) >> rsp=0xc8492d14 rfp=0xc8492d5c >> r10=0xc4bc0fcc r9=0x00008000 >> r8=0x00006034 r7=0xc8492df4 r6=0xc1976800 r5=0x00000800 >> r4=0x00000000 >> nfsm_uiotombuf() at nfsm_uiotombuf+0x10 >> scp=0xc0a86634 rlv=0xc0a8e8f4 (nfs_writerpc+0x1a8) >> rsp=0xc8492d60 rfp=0xc8492ddc >> r10=0xc3884910 r9=0x00008000 >> r8=0xc1acb000 r7=0x00008000 r6=0xc8492df4 r5=0xc1979900 >> r4=0x00000000 >> nfs_writerpc() at nfs_writerpc+0x10 >> scp=0xc0a8e75c rlv=0xc0a7f680 (nfs_doio+0x204) >> rsp=0xc8492de0 rfp=0xc8492e4c >> r10=0xc3884910 r9=0xc235cca8 >> r8=0x00008000 r7=0x00000000 r6=0x00000000 r5=0x000000c0 >> r4=0x00000000 >> nfs_doio() at nfs_doio+0x10 >> scp=0xc0a7f48c rlv=0xc0a871d8 (nfs_nfsiodnew+0x3c4) >> rsp=0xc8492e50 rfp=0xc8492e80 >> r10=0x00000000 r9=0xc0d13ab4 >> r8=0xc0d13990 r7=0x00000006 r6=0x00000000 r5=0xc1acb000 >> r4=0xc3884910 >> nfs_nfsiodnew() at nfs_nfsiodnew+0x2ac >> scp=0xc0a870c0 rlv=0xc0974b84 (fork_exit+0x64) >> rsp=0xc8492e84 rfp=0xc8492ea8 >> r10=0xc0a870b0 r9=0xc0d1f6c0 >> r8=0xc0d13368 r7=0xc1c6a828 r6=0xc8492eac r5=0xc0d1f6c0 >> r4=0xc22bd6f0 >> fork_exit() at fork_exit+0x10 >> scp=0xc0974b30 rlv=0xc0af6190 (fork_trampoline+0x14) >> rsp=0xc8492eac rfp=0x00000000 >> r10=0xc0d1f6c0 r8=0x00000104 >> r7=0xc0ae7f4c r6=0xc8492eac r5=0xc0d13368 r4=0xc0a870b0 >> >> >> FYI, >> >> -- >> Marcel Moolenaar >> xcllnt@mac.com >> >> >> >> _______________________________________________ >> 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" -- Alexandr Rybalko From owner-freebsd-arm@FreeBSD.ORG Thu Oct 8 04:12:57 2009 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8648F1065670 for ; Thu, 8 Oct 2009 04:12:57 +0000 (UTC) (envelope-from franson@gmail.com) Received: from mail-iw0-f190.google.com (mail-iw0-f190.google.com [209.85.223.190]) by mx1.freebsd.org (Postfix) with ESMTP id 4E8B08FC1E for ; Thu, 8 Oct 2009 04:12:57 +0000 (UTC) Received: by iwn28 with SMTP id 28so1957775iwn.3 for ; Wed, 07 Oct 2009 21:12:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type; bh=yHoSU9NX2ocvCqKw6B8yZCJOKOxkT4dHajtlZPxIb8w=; b=UAROFzKUN6RoM55DFkyUSf3TbQPaZWDYSbOn6JzSefNkfw2wztZugF0sbGbloY6z0b 0acbScoDpyZ559i/I/tVNiIaOX6arfdm0Aetpnij4urOSOzRto2ycPeQkGo640NeKN8F f18IuxOcUwrkgCB8a3qBBPgsjYWsxE0YblXDE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=jF87tYoeUDRK03cx7kw3HtGRCoyLoVeoCS8mMdQZQ6bhMmMm3R5RvWlxY76SkkdDSi +1Ca7LY8/75UdccH6F1aOHK7ZnP4MQkKfJyP1kpEF+2N/x6LHBYx+138EvPC8EXJgYv3 s7eTLlBp76z9XdcQ/JyLwe8FWvTQJf7EQeKb4= MIME-Version: 1.0 Sender: franson@gmail.com Received: by 10.231.42.150 with SMTP id s22mr1504738ibe.22.1254975175851; Wed, 07 Oct 2009 21:12:55 -0700 (PDT) In-Reply-To: <20091007095550.5cec1f93@fubar.geek.nz> References: <20091007095550.5cec1f93@fubar.geek.nz> Date: Thu, 8 Oct 2009 12:12:55 +0800 X-Google-Sender-Auth: 7f443301516273d5 Message-ID: From: quickembed To: Andrew Turner Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-arm@freebsd.org Subject: Re: friendly arm board X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 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, 08 Oct 2009 04:12:57 -0000 Glad to hear that you boot up FreeBSD on the board, however making each driver work does take effort, like usb, lcd, speaker etc. maybe you can merge some some code from the package of the board. 6410 is different, it is ARM11, 2440 is ARM9, so expect difference. On Wed, Oct 7, 2009 at 4:55 AM, Andrew Turner wrote: > On Tue, 6 Oct 2009 17:59:18 +0800 > quickembed wrote: > >> find types of ARM board here: >> http://www.quickembed.com/Tools/Shop/ARM/Index.html >> They provide linux support, like mini 2440 and it is said that also >> android is supported by 6410 now! > I have a mini2440 sitting on my desk that I have had running FreeBSD to > single-user mode. I'm unable to boot FreeBSD with USB support on it > though so I haven't managed multi-user mode. > > As far as I know there is nobody working on S3C6410 support. I don't > know how similar the peripherals on the chip are to the S3C24x0 chips > to know how difficult it would be to port FreeBSD to it. > > Andrew > From owner-freebsd-arm@FreeBSD.ORG Thu Oct 8 14:18:56 2009 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ABAAF106566B for ; Thu, 8 Oct 2009 14:18:56 +0000 (UTC) (envelope-from gballet@gmail.com) Received: from mail-ew0-f218.google.com (mail-ew0-f218.google.com [209.85.219.218]) by mx1.freebsd.org (Postfix) with ESMTP id 44A168FC0A for ; Thu, 8 Oct 2009 14:18:55 +0000 (UTC) Received: by ewy18 with SMTP id 18so135561ewy.43 for ; Thu, 08 Oct 2009 07:18:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=hYR9WzTkBN+88dT0q4AkbIraZYl6/0lo6LKNnAvAQfU=; b=Pqq9PqDx2wB1yG2c/hJmN96gioyhzvz7aiSRsV8zqjmRxPD/A2gL68ZqIAKwPdC2q7 jQ+3zhn/w8HidAk0ZYkr/HNkl+AsQaKs9qj54VhoLLKEbpD1E91DTU1mPxwtMOtJMU0t UZ1u7gmAL7Bh9zTQrutgOBOZ9Y6fsyvDdjvW0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=MGKoF/BfR+V2A9YVaf4kFc0I2eQflIAWysEunW7nkyB7GzWtVUJEjhdc6ifyA+agHY HxzXnn9XZbqplARqez1Jlt5bzkF++Fvavjt5SO4yu6ZTlxS2d05F+8Nm8g2YDyK5nEWo 2UKdxn5Q6P5EC/pPm5PsA+8BGTj3RrYwQRHL4= MIME-Version: 1.0 Received: by 10.211.131.11 with SMTP id i11mr8114100ebn.68.1255011535274; Thu, 08 Oct 2009 07:18:55 -0700 (PDT) Date: Thu, 8 Oct 2009 16:18:55 +0200 Message-ID: From: Guillaume Ballet To: freebsd-arm@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Adding members to struct cpu_functions X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 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, 08 Oct 2009 14:18:56 -0000 Hello list, I am continuing my effort to port FreeBSD to the BeagleBoard. I reached the point where the system prompts for the root filesystem. I am therefore cleaning up my code and will then post it to this list for comments. I still have a few hacky fixups to remove before it becomes readable :) I know that Mark Tinguely, whose help has been precious in this endeavor, has some patches ready for ARMv6 cache management, so I did not focus on this. At the moment, I am using backward-compatibility for the TLB format. I want to start using the ARMv6 TLB format. My current problem is that most of the arch-dependent code uses macros that are defined to match the pre-ARMv6 TLB format. There are several ways of fixing this, including defining these macros depending on some symbol such as _ARM_ARCH_* or CPU_ARM*. I am however no friend of heavy preprocessor flagging. What if instead, cpu_functions was extended to include fields like the prototype for TLB entries of each size? For example, take this patch to the following excerpt from pmap_map_chunk in sys/arm/arm/pmap.c: /* See if we can use a L2 large page mapping. */ if (L2_L_MAPPABLE_P(va, pa, resid)) { #ifdef VERBOSE_INIT_ARM printf("L"); #endif for (i = 0; i < 16; i++) { pte[l2pte_index(va) + i] = - L2_L_PROTO | pa | + cpufuncs.cf_l2_l_proto | pa | - L2_L_PROT(PTE_KERNEL, prot) | f2l; + cpufuncs.l2_l_prot(PTE_KERNEL, prot) | f2l; PTE_SYNC(&pte[l2pte_index(va) + i]); } va += L2_L_SIZE; pa += L2_L_SIZE; resid -= L2_L_SIZE; continue; } Would that be acceptable? Now, assuming people agree with this change, that would only be a first step because all values for cpufuncs are defined in the same file (cpufunc.c), which is guarded with as many CPU_ARMx defines as there are cpu flavors. Is there a specific reason for all these structures to be defined in a same file, instead of defining it in a platform- or cpu-specific file and using the files.* to select the appropriate cpufunc flavor in the build system? Guillaume From owner-freebsd-arm@FreeBSD.ORG Thu Oct 8 16:13:57 2009 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 118921065670 for ; Thu, 8 Oct 2009 16:13:57 +0000 (UTC) (envelope-from tinguely@casselton.net) Received: from casselton.net (casselton.net [63.165.140.2]) by mx1.freebsd.org (Postfix) with ESMTP id BCB998FC08 for ; Thu, 8 Oct 2009 16:13:56 +0000 (UTC) Received: from casselton.net (localhost [127.0.0.1]) by casselton.net (8.14.3/8.14.3) with ESMTP id n98GDtAM053540; Thu, 8 Oct 2009 11:13:55 -0500 (CDT) (envelope-from tinguely@casselton.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=casselton.net; s=ccnMail; t=1255018435; bh=NpxRtCj9M0cYJlfTZ6bCBaAiErIuHcVdbIIS5jH6jjc=; h=Date:From:Message-Id:To:Subject:In-Reply-To; b=HkNaxfqtXpm/ePfxOvcyZ54LmLwcq2NX8BXLvNqOsMXFZkUjt5E5sY3GfSKucCqZ9 1tORCiQ0X5oDxcnvkmhCKxorwkE/MCcccPw5BZUCVohuUIIg+x2NNPL1M5t15WgfNx 2x/BiznLEWhW66oekSTNXDjWjRfTVYT54oSoCSBc= Received: (from tinguely@localhost) by casselton.net (8.14.3/8.14.2/Submit) id n98GDt7r053539; Thu, 8 Oct 2009 11:13:55 -0500 (CDT) (envelope-from tinguely) Date: Thu, 8 Oct 2009 11:13:55 -0500 (CDT) From: Mark Tinguely Message-Id: <200910081613.n98GDt7r053539@casselton.net> To: freebsd-arm@freebsd.org, gballet@gmail.com In-Reply-To: X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.3.2 (casselton.net [127.0.0.1]); Thu, 08 Oct 2009 11:13:55 -0500 (CDT) Cc: Subject: Re: Adding members to struct cpu_functions X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 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, 08 Oct 2009 16:13:57 -0000 > I am continuing my effort to port FreeBSD to the BeagleBoard. I > reached the point where the system prompts for the root filesystem. I > am therefore cleaning up my code and will then post it to this list > for comments. I still have a few hacky fixups to remove before it > becomes readable :) Congratulations. > I know that Mark Tinguely, whose help has been precious in this > endeavor, has some patches ready for ARMv6 cache management, so I did > not focus on this. It is all untested. I am wondering to myself with small number of TBL on the OMAP, should we use the new ASID process identifier and not flush the TBLs or just flush them on context switch. > At the moment, I am using backward-compatibility for the TLB format. I > want to start using the ARMv6 TLB format. My current problem is that > most of the arch-dependent code uses macros that are defined to match > the pre-ARMv6 TLB format. There are several ways of fixing this, > including defining these macros depending on some symbol such as > _ARM_ARCH_* or CPU_ARM*. I am however no friend of heavy preprocessor > flagging. What if instead, cpu_functions was extended to include > fields like the prototype for TLB entries of each size? For example, > take this patch to the following excerpt from pmap_map_chunk in > sys/arm/arm/pmap.c: [deleted example] > Now, assuming people agree with this change, that would only be a > first step because all values for cpufuncs are defined in the same > file (cpufunc.c), which is guarded with as many CPU_ARMx defines as > there are cpu flavors. Is there a specific reason for all these > structures to be defined in a same file, instead of defining it in a > platform- or cpu-specific file and using the files.* to select the > appropriate cpufunc flavor in the build system? I have been pondering the current L1/L2 (in this context we mean Page Directory entries and Page Table entries, not cache levels) values for cache, protection, the C/B/TEX (and now the global, secure, and no execute) and masks for a while. Some of these values are variables and some are defines. It can be confusing to track down a value for a ARCH/board. ARM kernels are very specific for processor and board. IMO, we should be moving some of these settings into a processor [and board] directories/files and make them more consistant. I am not saying anything bad about NetBSD that originate these files nor the additions that have been made since, what I am saying is it would be nice to have a big reorganization; that takes time and therefore money. -- on a tangent about the future -- Since the ARMv7 is coming to FreeBSD, there are other ARMv4/5 vrs ARMv6/7 questions, the most important is should we break the new ARM chips with their physical tagged caches to another subbranch or define it into the existing code? One example of the existing pmap code that does not mesh well with ARMv6/7 is the exisiting flush of the level 2 cache because the old archs have VIVT level 2 caches). ARMv6/7 level 2 caches are PIPT, and would not be flushed until DMA time. A simple solution would be if an arch needs to flush the level 2 cache when it flushes the level 1 cache, then it should do so in the level 1 cache flushing routine. --Mark Tinguely. From owner-freebsd-arm@FreeBSD.ORG Sat Oct 10 18:16:48 2009 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E7B15106568B for ; Sat, 10 Oct 2009 18:16:48 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from asmtpout028.mac.com (asmtpout028.mac.com [17.148.16.103]) by mx1.freebsd.org (Postfix) with ESMTP id D74458FC0C for ; Sat, 10 Oct 2009 18:16:48 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii; format=flowed; delsp=yes Received: from macbook-pro.lan.xcllnt.net (mail.xcllnt.net [75.101.29.67]) by asmtp028.mac.com (Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 32bit)) with ESMTPSA id <0KRB00ECY9FZ2Y60@asmtp028.mac.com> for arm@freebsd.org; Sat, 10 Oct 2009 11:16:48 -0700 (PDT) From: Marcel Moolenaar Date: Sat, 10 Oct 2009 11:16:47 -0700 Message-id: To: arm@freebsd.org X-Mailer: Apple Mail (2.1076) Cc: Subject: panic: _mtx_lock_sleep: recursed on non-recursive mutex pmap X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 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, 10 Oct 2009 18:16:49 -0000 Hardware: o Marvell DB-78XXX o 500GB USB disk (da0, mounted /) o 500GB SATA disk (ad0, mounted /mnt) o 1Gb ethernet (NFS mounted /nfs) While running rsync from da0p1 to ad0p1 without crossing file systems (i.e. NFS not involved) I got the following panic: # sudo rsync -alHv --delete --one-file-system / /mnt/ sending incremental file list ./ .cshrc .profile ... usr/local/man/man1/pod2html.1.gz usr/local/man/man1/pod2latex.1.gz usr/local/man/man1/pod2man.1.gz panic: _mtx_lock_sleep: recursed on non-recursive mutex pmap @ / zmirror/nfs/freebsd/base/head/sys/arm/arm/pmap.c:1916 KDB: enter: panic [thread pid 857 tid 100051 ] Stopped at kdb_enter+0x48: ldrb r15, [r15, r15, ror r15]! db> It looks like cron is the culprit: db> show alllocks Process 857 (cron) thread 0xc3984d80 (100051) exclusive sleep mutex pmap (pmap) r = 0 (0xc3a330b0) locked @ /zmirror/ nfs/freebsd/base/head/sys/arm/arm/pmap.c:3254 exclusive sleep mutex vm page queue mutex (vm page queue mutex) r = 1 (0xc0d897c0) locked @ /zmirror/nfs/freebsd/base/head/sys/arm/arm/ pmap.c:1915 exclusive sx user map (user map) r = 0 (0xc3a7752c) locked @ /zmirror/ nfs/freebsd/base/head/sys/vm/vm_map.c:2981 exclusive sx user map (user map) r = 0 (0xc3a33048) locked @ /zmirror/ nfs/freebsd/base/head/sys/vm/vm_map.c:2973 db> bt Tracing pid 857 tid 100051 td 0xc3984d80 db_trace_thread() at db_trace_thread+0x10 scp=0xc0b47420 rlv=0xc0919f8c (db_command_init+0x4d4) rsp=0xd1c6b83c rfp=0xd1c6b85c r10=0x00000001 r9=0xc0c290b0 r8=0xc0c20e4c r7=0xc0c20620 r6=0x00000010 r5=0x00000000 r4=0xc3984d80 db_command_init() at db_command_init+0x454 scp=0xc0919f0c rlv=0xc0919738 (db_skip_to_eol+0x38c) rsp=0xd1c6b860 rfp=0xd1c6b904 r6=0x00000002 r5=0x00000000 r4=0xc0bfb5c8 db_skip_to_eol() at db_skip_to_eol+0x1d0 scp=0xc091957c rlv=0xc0919954 (db_command_loop+0x50) rsp=0xd1c6b908 rfp=0xd1c6b918 r10=0x00000001 r8=0x00000000 r7=0xd1c6bae4 r6=0xc0c290ac r5=0x000000c0 r4=0xc0c2061c db_command_loop() at db_command_loop+0x18 scp=0xc091991c rlv=0xc091bb9c (X_db_sym_numargs+0xa0) rsp=0xd1c6b91c rfp=0xd1c6ba38 r4=0xd1c6b920 X_db_sym_numargs() at X_db_sym_numargs+0x18 scp=0xc091bb14 rlv=0xc09fe9a8 (kdb_trap+0xb0) rsp=0xd1c6ba3c rfp=0xd1c6ba64 r4=0x000000c0 kdb_trap() at kdb_trap+0x10 scp=0xc09fe908 rlv=0xc0b57ed0 (undefinedinstruction+0x124) rsp=0xd1c6ba68 rfp=0xd1c6bae0 r10=0xc3984d80 r9=0xc0d94e80 r8=0xc09fe69c r7=0xe7ffffff r6=0xd1c6bae4 r5=0x00000000 r4=0x00000000 undefinedinstruction() at undefinedinstruction+0x10 scp=0xc0b57dbc rlv=0xc0b48ea8 (address_exception_entry+0x50) rsp=0xd1c6bae4 rfp=0xd1c6bb44 r10=0xc0d94e80 r9=0x00000001 r8=0x0000077c r7=0xc3984d80 r6=0xc0c252f8 r5=0xffff1004 r4=0x00000000 kdb_enter() at kdb_enter+0x14 scp=0xc09fe668 rlv=0xc09d2304 (panic+0xa0) rsp=0xd1c6bb48 rfp=0xd1c6bb5c r5=0xc0b936f8 r4=0x00000100 panic() at panic+0x1c scp=0xc09d2280 rlv=0xc09c410c (_mtx_lock_sleep+0x130) rsp=0xd1c6bb70 rfp=0xd1c6bb88 _mtx_lock_sleep() at _mtx_lock_sleep+0x10 scp=0xc09c3fec rlv=0xc09c41ec (_mtx_lock_flags+0xd4) rsp=0xd1c6bb8c rfp=0xd1c6bbb4 r6=0x00000000 r5=0xc3a330b0 r4=0x00000000 _mtx_lock_flags() at _mtx_lock_flags+0x10 scp=0xc09c4128 rlv=0xc0b4dfe4 (pmap_fault_fixup+0x48) rsp=0xd1c6bbb8 rfp=0xd1c6bbec r10=0xd1c6bc94 r8=0x00000001 r7=0xc3984d80 r6=0x00019000 r5=0xc3a330b0 r4=0x00000000 pmap_fault_fixup() at pmap_fault_fixup+0x10 scp=0xc0b4dfac rlv=0xc0b571a8 (data_abort_handler+0x16c) rsp=0xd1c6bbf0 rfp=0xd1c6bc90 r10=0xd1c6bc94 r9=0xd1c6bef8 r8=0x00000001 r7=0xc3984d80 r6=0x000e7000 r5=0x00019000 r4=0x00000007 data_abort_handler() at data_abort_handler+0x10 scp=0xc0b5704c rlv=0xc0b48ea8 (address_exception_entry+0x50) rsp=0xd1c6bc94 rfp=0xd1c6bd20 r10=0xc3a330b0 r9=0x00100000 r8=0x000e9000 r7=0x00019000 r6=0x000e7000 r5=0xffff1004 r4=0x00017000 pmap_protect() at pmap_protect+0x10 scp=0xc0b50970 rlv=0xc0b2f460 (vmspace_fork+0x420) rsp=0xd1c6bd24 rfp=0xd1c6bd60 r10=0xc3a33000 r9=0x00008000 r8=0xc3a774e4 r7=0x00000001 r6=0xc3a1c168 r5=0xc3a5cca8 r4=0x00000000 vmspace_fork() at vmspace_fork+0x10 scp=0xc0b2f050 rlv=0xc09ad6cc (fork1+0x100) rsp=0xd1c6bd64 rfp=0xd1c6bdbc r10=0xc397f834 r9=0xc3984d80 r8=0x00000014 r7=0xd1c6beac r6=0xc3a30af0 r5=0x00000002 r4=0x00000000 fork1() at fork1+0x10 scp=0xc09ad5dc rlv=0xc09ae848 (fork+0x24) rsp=0xd1c6bdc0 rfp=0xd1c6bdd8 r10=0xc397f834 r9=0x00000000 r8=0xc0c05360 r7=0xd1c6beac r6=0x00000002 r5=0xc3984d80 r4=0xc3984d80 fork() at fork+0x10 scp=0xc09ae834 rlv=0xc0b57674 (swi_handler+0x128) rsp=0xd1c6bddc rfp=0xd1c6bea8 r4=0x00000000 swi_handler() at swi_handler+0x10 scp=0xc0b5755c rlv=0xc0b48c80 (swi_entry+0x40) rsp=0xd1c6beac rfp=0xbfffed20 r10=0x0000000b r9=0x00000000 r8=0x00000000 r7=0x000187c8 r6=0x00000000 r5=0x20215028 r4=0x20216040 db> ps pid ppid pgrp uid state wmesg wchan cmd 970 969 968 0 R+ rsync 969 968 968 0 S+ select 0xc3a21324 rsync 968 907 968 0 R+ rsync 907 906 907 501 S+ pause 0xc38d388c tcsh 906 1 906 0 Ss+ wait 0xc3a302bc login 884 1 884 0 Ss select 0xc38f8be4 inetd 857 1 857 0 Rs CPU 0 cron 851 1 851 25 Ss pause 0xc3a30058 sendmail 847 1 847 0 Ss select 0xc3a203a4 sendmail 842 1 842 0 Ss select 0xc3a201a4 sshd 811 1 811 1 Ss sbwait 0xc3a22254 rwhod 781 1 781 0 Ss select 0xc38c7764 ntpd 717 1 717 0 Ss rpcsvc 0xc38ec910 NLM: master 711 1 711 0 Ss select 0xc38dfae4 rpc.statd 636 1 636 0 Ss select 0xc38ec624 ypbind 618 1 618 0 Ss select 0xc38f8064 rpcbind 598 1 598 0 Ss select 0xc38ecb64 syslogd 482 1 482 0 Ss select 0xc37589e4 devd 481 1 481 65 Ss select 0xc386c6e4 dhclient 441 1 441 0 Ss select 0xc38ecd24 dhclient 16 0 0 0 SL - 0xc0c25554 [schedcpu] 15 0 0 0 SL syncer 0xc0d83f38 [syncer] 14 0 0 0 SL vlruwt 0xc38d3000 [vnlru] 9 0 0 0 SL psleep 0xc0d83cb4 [bufdaemon] 8 0 0 0 SL pgzero 0xc0d89d4c [pagezero] 7 0 0 0 SL pollid 0xc0c24de4 [idlepoll] 6 0 0 0 SL psleep 0xc0d89848 [pagedaemon] 13 0 0 0 SL (threaded) [usb] 100032 D - 0xc3679d0c [usbus2] 100031 D - 0xc3679cdc [usbus2] 100030 D - 0xc3679cac [usbus2] 100029 D - 0xc3679c7c [usbus2] 100027 D - 0xc3657d0c [usbus1] 100026 D - 0xc3657cdc [usbus1] 100025 D - 0xc3657cac [usbus1] 100024 D - 0xc3657c7c [usbus1] 100022 D - 0xc3634d0c [usbus0] 100021 D - 0xc3634cdc [usbus0] 100020 D - 0xc3634cac [usbus0] 100019 D - 0xc3634c7c [usbus0] 5 0 0 0 SL ccb_scan 0xc0c1fa24 [xpt_thrd] 12 0 0 0 SL - 0xc0c25554 [yarrow] 4 0 0 0 SL - 0xc0c22de8 [g_down] 3 0 0 0 SL - 0xc0c22de4 [g_up] 2 0 0 0 SL - 0xc0c22ddc [g_event] 11 0 0 0 WL (threaded) [intr] 100037 I [intr26: sata0] 100036 I [intr46: mge1] 100035 I [intr45: mge1] 100034 I [intr42: mge0] 100033 I [intr41: mge0] 100028 I [intr18: ehci2] 100023 I [intr17: ehci1] 100018 I [intr16: ehci0] 100017 I [swi0: uart uart] 100015 I [swi2: cambio] 100013 I [swi6: task queue] 100012 I [swi6: Giant taskq] 100010 I [swi5: +] 100005 I [swi4: clock] 100004 I [swi3: vm] 100003 I [swi1: netisr 0] 10 0 0 0 RL [idle] 1 0 1 0 SLs wait 0xc35bf000 [init] 0 0 0 0 SLs (threaded) [kernel] 100016 D - 0xc361cd80 [kqueue taskq] 100011 D - 0xc361d140 [thread taskq] 100000 D sched 0xc0c22e38 [swapper] db> show intrcnt irq8: timer0 90926 irq12: uart0 37904 irq16: ehci0 75948 irq41: mge0 679 irq42: mge0 660 irq26: sata0 265343 FYI, -- Marcel Moolenaar xcllnt@mac.com