From owner-freebsd-arm@FreeBSD.ORG Sun Feb 6 13:31:48 2011 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 67AA5106566C for ; Sun, 6 Feb 2011 13:31:48 +0000 (UTC) (envelope-from isp.skynet@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id EDDAA8FC08 for ; Sun, 6 Feb 2011 13:31:47 +0000 (UTC) Received: by wyf19 with SMTP id 19so3865197wyf.13 for ; Sun, 06 Feb 2011 05:31:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:from:to:subject:date:message-id:mime-version :content-type:x-mailer:thread-index:x-mimeole; bh=24MPb3RZNg3e9/bsJcNtngK4w580RWy7Y2oZ0YfIhYs=; b=RtbCEzDdFGx2tEGuCV5G3lJ+p2Mxq+imxlQrtbzNJjKwSMN81HG73j62XSjmA0o5fB UsH1EilvsTCQCWcL7pr4Ze693zt2OIMokno6Mfx3W0iGVPwISx1sac47YAIY/vtzZr5b abqa+FUxddj2kP3hqzVpj8z8zMoiVzlmviu/g= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:subject:date:message-id:mime-version:content-type:x-mailer :thread-index:x-mimeole; b=WY5OfL4gxGhtrHnFzMB3ofXLVyed7hvB+FFca7/yLsF+V8tta7objDdG+YGBsxoU6O 0eZKkV6qwTgFvk8r26pG0aIl+Nrk/p63c2wGHAfXchS0idtvMpMRlFkYOPlCC3Oqv+n2 2rNsNo3qMB5tB4Le28zvRJ2q5EeAMSEAfS8yQ= Received: by 10.227.127.141 with SMTP id g13mr14661281wbs.62.1296997498998; Sun, 06 Feb 2011 05:04:58 -0800 (PST) Received: from wispskynet ([82.213.59.18]) by mx.google.com with ESMTPS id f52sm1547646wes.35.2011.02.06.05.04.55 (version=SSLv3 cipher=RC4-MD5); Sun, 06 Feb 2011 05:04:57 -0800 (PST) From: "Sky Net" To: Date: Sun, 6 Feb 2011 15:06:55 +0200 Message-ID: <58CD61A782A34C788A93F8DA363A7DEA@wispskynet> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcvF/ro2PhAFCBwTR8GHL6qxchFmDQ== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5994 X-Mailman-Approved-At: Sun, 06 Feb 2011 13:42:05 +0000 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Avila Network Platform: GW2348-4, GW2348-2, GW2347 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, 06 Feb 2011 13:31:48 -0000 HELLO I have board Avila GW2348-4 Network Platform Plz help me to config it thank you From owner-freebsd-arm@FreeBSD.ORG Sun Feb 6 18:17:03 2011 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 528B4106564A for ; Sun, 6 Feb 2011 18:17:03 +0000 (UTC) (envelope-from torfinn.ingolfsen@broadpark.no) Received: from thalia-smout.broadpark.no (thalia-smout.broadpark.no [80.202.8.21]) by mx1.freebsd.org (Postfix) with ESMTP id 0D2FC8FC08 for ; Sun, 6 Feb 2011 18:17:02 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from terra-smin.broadpark.no ([80.202.8.13]) by thalia-smout.broadpark.no (Sun Java(tm) System Messaging Server 7u3-15.01 64bit (built Feb 12 2010)) with ESMTP id <0LG7007U1HCC5P30@thalia-smout.broadpark.no> for freebsd-arm@FreeBSD.org; Sun, 06 Feb 2011 18:17:00 +0100 (CET) Received: from kg-v2.kg4.no ([84.48.120.77]) by terra-smin.broadpark.no (Sun Java(tm) System Messaging Server 7u3-15.01 64bit (built Feb 12 2010)) with SMTP id <0LG700H5VHCB7E80@terra-smin.broadpark.no> for freebsd-arm@FreeBSD.org; Sun, 06 Feb 2011 18:17:00 +0100 (CET) Date: Sun, 06 Feb 2011 18:16:59 +0100 From: Torfinn Ingolfsen To: freebsd-arm@FreeBSD.org Message-id: <20110206181659.869861bf.torfinn.ingolfsen@broadpark.no> X-Mailer: Sylpheed 3.0.3 (GTK+ 2.22.1; amd64-portbld-freebsd8.1) X-Face: "t9w2,-X@O^I`jVW\sonI3.,36KBLZE*AL[y9lL[PyFD*r_S:dIL9c[8Y>V42R0"!"yb_zN,f#%.[PYYNq; m"_0v; ~rUM2Yy!zmkh)3&U|u!=T(zyv,MHJv"nDH>OJ`t(@mil461d_B'Uo|'nMwlKe0Mv=kvV?Nh@>Hb<3s_z2jYgZhPb@?Wi^x1a~Hplz1.zH Cc: Subject: FreeBSD on a DockStar - doesn't mount root 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, 06 Feb 2011 18:17:03 -0000 Hello, I have a Seagate DockStar (Sheevaplug derivative) and have followed this guide[1] to install FreeBSD on it. In particular: - installed a new uboot[2], this works nicely - prepared a new usb memory stick[3], which behaves well when connected to my workstation - installed the pre-built distribution[4] on the memory stick - configured uboot as mentioned here[5] When I boot the DockStar with this usb memory stick, the kernel boots, but then it stops because it fails to mount root. Relevant parts of the output: ugen0.3: at usbus0 umass0: on usbus0 umass0: SCSI over Bulk-Only; quirks = 0x0000 umass0:0:0:-1: Attached to scbus0 Trying to mount root from ufs:/dev/ufs/kirkwoodroot ROOT MOUNT ERROR: If you have invalid mount options, reboot, and first try the following from the loader prompt: set vfs.root.mountfrom.options=rw and then remove invalid mount options from /etc/fstab. Loader variables: vfs.root.mountfrom= vfs.root.mountfrom.options= Manual root filesystem specification: : Mount using filesystem eg. ufs:/dev/da0s1a eg. cd9660:/dev/acd0 This is equivalent to: mount -t cd9660 /dev/acd0 / ? List valid disk boot devices Abort manual input mountroot> at this point trying '?' gives no GEOM devices, and also trying to manually input ufs:/dev/ufs/kirkwoodroot doesn't help either. Yes, I have verified on my workstation that the memory stick have /dev/ufs/kirkwoodroot and that I can mount the partition from it. What can I do to fix the problem? As usual, I have a worklog page[6] for the dockstar and FreeBSD. References: 1) http://cooltrainer.org/projects/freebsd-kirkwood/ 2) http://jeff.doozan.com/debian/uboot/ 3) http://cooltrainer.org/projects/freebsd-kirkwood/building/#prepare-drive 4) http://cooltrainer.org/projects/freebsd-kirkwood/distribution/ 5) http://cooltrainer.org/projects/freebsd-kirkwood/installation/ 6) http://sites.google.com/site/tingox/seagate_dockstar_freebsd -- Regards, Torfinn Ingolfsen From owner-freebsd-arm@FreeBSD.ORG Sun Feb 6 19:05:51 2011 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 78E17106566B for ; Sun, 6 Feb 2011 19:05:51 +0000 (UTC) (envelope-from freebsd-arm@dino.sk) Received: from loki.netlab.sk (ns3.netlab.sk [84.245.65.11]) by mx1.freebsd.org (Postfix) with ESMTP id 385AD8FC17 for ; Sun, 6 Feb 2011 19:05:50 +0000 (UTC) Received: from door.dino.sk (fw1.dino.sk [84.245.95.252]) (AUTH: PLAIN milan, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by loki.netlab.sk with esmtp; Sun, 06 Feb 2011 19:53:42 +0100 id 00033C09.4D4EEE36.000062C6 From: Milan Obuch To: freebsd-arm@freebsd.org Date: Sun, 6 Feb 2011 19:55:37 +0100 User-Agent: KMail/1.13.5 (FreeBSD/8.2-PRERELEASE; KDE/4.5.5; i386; ; ) References: <20110206181659.869861bf.torfinn.ingolfsen@broadpark.no> In-Reply-To: <20110206181659.869861bf.torfinn.ingolfsen@broadpark.no> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201102061955.38635.freebsd-arm@dino.sk> Subject: Re: FreeBSD on a DockStar - doesn't mount root 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, 06 Feb 2011 19:05:51 -0000 On Sunday 06 February 2011 18:16:59 Torfinn Ingolfsen wrote: > Hello, > > I have a Seagate DockStar (Sheevaplug derivative) and have followed > this guide[1] to install FreeBSD on it. In particular: > - installed a new uboot[2], this works nicely > - prepared a new usb memory stick[3], which behaves well when connected to > my workstation - installed the pre-built distribution[4] on the memory > stick > - configured uboot as mentioned here[5] > > When I boot the DockStar with this usb memory stick, the kernel boots, but > then it stops because it fails to mount root. Relevant parts of the > output: > ugen0.3: at usbus0 > umass0: on usbus0 > umass0: SCSI over Bulk-Only; quirks = 0x0000 > umass0:0:0:-1: Attached to scbus0 > Trying to mount root from ufs:/dev/ufs/kirkwoodroot > ROOT MOUNT ERROR: > If you have invalid mount options, reboot, and first try the following from > the loader prompt: > > set vfs.root.mountfrom.options=rw > > and then remove invalid mount options from /etc/fstab. > > Loader variables: > vfs.root.mountfrom= > vfs.root.mountfrom.options= > > Manual root filesystem specification: > : Mount using filesystem > eg. ufs:/dev/da0s1a > eg. cd9660:/dev/acd0 > This is equivalent to: mount -t cd9660 /dev/acd0 / > > ? List valid disk boot devices > Abort manual input > > mountroot> > > at this point trying '?' gives no GEOM devices, and also trying to manually > input ufs:/dev/ufs/kirkwoodroot > doesn't help either. Yes, I have verified on my workstation that the memory > stick have /dev/ufs/kirkwoodroot and that I can mount the partition from > it. > > What can I do to fix the problem? > Did you try typing several dots to test whether some more time to mount root device helps? I would try it, sometimes it helps... Just some more time for background tasks (one dot means one second, It I am not mistaken). Regards, Milan From owner-freebsd-arm@FreeBSD.ORG Sun Feb 6 21:38:16 2011 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 477A310656C6 for ; Sun, 6 Feb 2011 21:38:16 +0000 (UTC) (envelope-from stb@lassitu.de) Received: from gilb.zs64.net (gilb.zs64.net [IPv6:2001:470:1f0b:105e::1ea]) by mx1.freebsd.org (Postfix) with ESMTP id 008928FC23 for ; Sun, 6 Feb 2011 21:38:16 +0000 (UTC) Received: by gilb.zs64.net (Postfix, from stb@lassitu.de) id B599AD425F; Sun, 6 Feb 2011 22:38:14 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Stefan Bethke In-Reply-To: <20110206181659.869861bf.torfinn.ingolfsen@broadpark.no> Date: Sun, 6 Feb 2011 22:38:13 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <2BF83A01-C13F-4399-BF5F-D3300BC157D4@lassitu.de> References: <20110206181659.869861bf.torfinn.ingolfsen@broadpark.no> To: Torfinn Ingolfsen X-Mailer: Apple Mail (2.1082) Cc: freebsd-arm@FreeBSD.org Subject: Re: FreeBSD on a DockStar - doesn't mount root 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, 06 Feb 2011 21:38:16 -0000 Am 06.02.2011 um 18:16 schrieb Torfinn Ingolfsen: > at this point trying '?' gives no GEOM devices, and also trying to = manually input > ufs:/dev/ufs/kirkwoodroot > doesn't help either. Yes, I have verified on my workstation that the = memory stick have=20 > /dev/ufs/kirkwoodroot and that I can mount the partition from it. >=20 > What can I do to fix the problem? Does ufs:/dev/da0s2a work? What is the output form the mountroot prompt = when you enter "?"? Stefan --=20 Stefan Bethke Fon +49 151 14070811 From owner-freebsd-arm@FreeBSD.ORG Sun Feb 6 22:05:47 2011 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 929601065670 for ; Sun, 6 Feb 2011 22:05:47 +0000 (UTC) (envelope-from torfinn.ingolfsen@broadpark.no) Received: from thalia-smout.broadpark.no (thalia-smout.broadpark.no [80.202.8.21]) by mx1.freebsd.org (Postfix) with ESMTP id 4A90E8FC0A for ; Sun, 6 Feb 2011 22:05:47 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from terra-smin.broadpark.no ([80.202.8.13]) by thalia-smout.broadpark.no (Sun Java(tm) System Messaging Server 7u3-15.01 64bit (built Feb 12 2010)) with ESMTP id <0LG700DHXUPK6F20@thalia-smout.broadpark.no> for freebsd-arm@FreeBSD.org; Sun, 06 Feb 2011 23:05:44 +0100 (CET) Received: from kg-v2.kg4.no ([84.48.120.77]) by terra-smin.broadpark.no (Sun Java(tm) System Messaging Server 7u3-15.01 64bit (built Feb 12 2010)) with SMTP id <0LG700LFUUPK9240@terra-smin.broadpark.no> for freebsd-arm@FreeBSD.org; Sun, 06 Feb 2011 23:05:44 +0100 (CET) Date: Sun, 06 Feb 2011 23:05:44 +0100 From: Torfinn Ingolfsen To: freebsd-arm@FreeBSD.org Message-id: <20110206230544.ab104af3.torfinn.ingolfsen@broadpark.no> In-reply-to: <2BF83A01-C13F-4399-BF5F-D3300BC157D4@lassitu.de> References: <20110206181659.869861bf.torfinn.ingolfsen@broadpark.no> <2BF83A01-C13F-4399-BF5F-D3300BC157D4@lassitu.de> X-Mailer: Sylpheed 3.0.3 (GTK+ 2.22.1; amd64-portbld-freebsd8.1) X-Face: "t9w2,-X@O^I`jVW\sonI3.,36KBLZE*AL[y9lL[PyFD*r_S:dIL9c[8Y>V42R0"!"yb_zN,f#%.[PYYNq; m"_0v; ~rUM2Yy!zmkh)3&U|u!=T(zyv,MHJv"nDH>OJ`t(@mil461d_B'Uo|'nMwlKe0Mv=kvV?Nh@>Hb<3s_z2jYgZhPb@?Wi^x1a~Hplz1.zH Cc: Subject: Re: FreeBSD on a DockStar - doesn't mount root 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, 06 Feb 2011 22:05:47 -0000 On Sun, 06 Feb 2011 22:38:13 +0100 Stefan Bethke wrote: > Am 06.02.2011 um 18:16 schrieb Torfinn Ingolfsen: > > > at this point trying '?' gives no GEOM devices, and also trying to manually input > > ufs:/dev/ufs/kirkwoodroot > > doesn't help either. Yes, I have verified on my workstation that the memory stick have > > /dev/ufs/kirkwoodroot and that I can mount the partition from it. > > > > What can I do to fix the problem? > > Does ufs:/dev/da0s2a work? What is the output form the mountroot prompt when you enter "?"? No, ufs:/dev/da0s2a does not work. The output when I enter "?" is just a single line (a headline or something) which says "GEOM devices" or something to that effect, then it is back to the mountroot prompt again. -- Torfinn From owner-freebsd-arm@FreeBSD.ORG Sun Feb 6 22:17:22 2011 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 41D61106566C for ; Sun, 6 Feb 2011 22:17:22 +0000 (UTC) (envelope-from torfinn.ingolfsen@broadpark.no) Received: from thalia-smout.broadpark.no (thalia-smout.broadpark.no [80.202.8.21]) by mx1.freebsd.org (Postfix) with ESMTP id EE7238FC14 for ; Sun, 6 Feb 2011 22:17:21 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from terra-smin.broadpark.no ([80.202.8.13]) by thalia-smout.broadpark.no (Sun Java(tm) System Messaging Server 7u3-15.01 64bit (built Feb 12 2010)) with ESMTP id <0LG700DNCV8W6F30@thalia-smout.broadpark.no> for freebsd-arm@FreeBSD.org; Sun, 06 Feb 2011 23:17:20 +0100 (CET) Received: from kg-v2.kg4.no ([84.48.120.77]) by terra-smin.broadpark.no (Sun Java(tm) System Messaging Server 7u3-15.01 64bit (built Feb 12 2010)) with SMTP id <0LG700KUTV8WJ3O0@terra-smin.broadpark.no> for freebsd-arm@FreeBSD.org; Sun, 06 Feb 2011 23:17:20 +0100 (CET) Date: Sun, 06 Feb 2011 23:17:20 +0100 From: Torfinn Ingolfsen To: freebsd-arm@FreeBSD.org Message-id: <20110206231720.e113a196.torfinn.ingolfsen@broadpark.no> In-reply-to: <201102061955.38635.freebsd-arm@dino.sk> References: <20110206181659.869861bf.torfinn.ingolfsen@broadpark.no> <201102061955.38635.freebsd-arm@dino.sk> X-Mailer: Sylpheed 3.0.3 (GTK+ 2.22.1; amd64-portbld-freebsd8.1) X-Face: "t9w2,-X@O^I`jVW\sonI3.,36KBLZE*AL[y9lL[PyFD*r_S:dIL9c[8Y>V42R0"!"yb_zN,f#%.[PYYNq; m"_0v; ~rUM2Yy!zmkh)3&U|u!=T(zyv,MHJv"nDH>OJ`t(@mil461d_B'Uo|'nMwlKe0Mv=kvV?Nh@>Hb<3s_z2jYgZhPb@?Wi^x1a~Hplz1.zH Cc: Subject: Re: FreeBSD on a DockStar - doesn't mount root 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, 06 Feb 2011 22:17:22 -0000 On Sun, 06 Feb 2011 19:55:37 +0100 Milan Obuch wrote: > Did you try typing several dots to test whether some more time to mount root > device helps? I would try it, sometimes it helps... Just some more time for > background tasks (one dot means one second, It I am not mistaken). I'm not really sure how it is suposed to be, I tried .....ufs:/dev/ufs/kirkwoodroot and that didn't have any effect. -- Torfinn From owner-freebsd-arm@FreeBSD.ORG Sun Feb 6 22:41:08 2011 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 911C01065670 for ; Sun, 6 Feb 2011 22:41:08 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe05.c2i.net [212.247.154.130]) by mx1.freebsd.org (Postfix) with ESMTP id 1D7798FC21 for ; Sun, 6 Feb 2011 22:41:07 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.1 cv=O4luLtK3s/BI/ZI2MixGyL7hJC8Dk2jKRuc55HZ6Kk0= c=1 sm=1 a=raTW6j-r9ywA:10 a=8nJEP1OIZ-IA:10 a=CL8lFSKtTFcA:10 a=i9M/sDlu2rpZ9XS819oYzg==:17 a=QyZfiG7-4r_6d6z0mgsA:9 a=M3D6KuWaQMZIKIW4RcsA:7 a=ELM3yaHBTS-DZYvIOeGoQaSELYwA:4 a=wPNLvfGTeEIA:10 a=i9M/sDlu2rpZ9XS819oYzg==:117 Received: from [188.126.198.129] (account mc467741@c2i.net HELO laptop002.hselasky.homeunix.org) by mailfe05.swip.net (CommuniGate Pro SMTP 5.2.19) with ESMTPA id 83281274; Sun, 06 Feb 2011 23:31:04 +0100 From: Hans Petter Selasky To: freebsd-arm@freebsd.org Date: Sun, 6 Feb 2011 23:31:01 +0100 User-Agent: KMail/1.13.5 (FreeBSD/8.2-PRERELEASE; KDE/4.4.5; amd64; ; ) References: <20110206181659.869861bf.torfinn.ingolfsen@broadpark.no> <201102061955.38635.freebsd-arm@dino.sk> <20110206231720.e113a196.torfinn.ingolfsen@broadpark.no> In-Reply-To: <20110206231720.e113a196.torfinn.ingolfsen@broadpark.no> X-Face: *nPdTl_}RuAI6^PVpA02T?$%Xa^>@hE0uyUIoiha$pC:9TVgl.Oq, NwSZ4V"|LR.+tj}g5 %V,x^qOs~mnU3]Gn; cQLv&.N>TrxmSFf+p6(30a/{)KUU!s}w\IhQBj}[g}bj0I3^glmC( :AuzV9:.hESm-x4h240C`9=w MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201102062331.01760.hselasky@c2i.net> Cc: Subject: Re: FreeBSD on a DockStar - doesn't mount root 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, 06 Feb 2011 22:41:08 -0000 On Sunday 06 February 2011 23:17:20 Torfinn Ingolfsen wrote: > On Sun, 06 Feb 2011 19:55:37 +0100 > > Milan Obuch wrote: > > Did you try typing several dots to test whether some more time to mount > > root device helps? I would try it, sometimes it helps... Just some more > > time for background tasks (one dot means one second, It I am not > > mistaken). > > I'm not really sure how it is suposed to be, I tried > .....ufs:/dev/ufs/kirkwoodroot > > and that didn't have any effect. Maybe you need to set the scsi delay sysctl, to give the drive more time to probe. Search the mailing lists :-) --HPS From owner-freebsd-arm@FreeBSD.ORG Mon Feb 7 11:06:56 2011 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 D98361065672 for ; Mon, 7 Feb 2011 11:06:56 +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 C85BA8FC1A for ; Mon, 7 Feb 2011 11:06:56 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p17B6uMA027686 for ; Mon, 7 Feb 2011 11:06:56 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p17B6uvC027684 for freebsd-arm@FreeBSD.org; Mon, 7 Feb 2011 11:06:56 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 7 Feb 2011 11:06:56 GMT Message-Id: <201102071106.p17B6uvC027684@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, 07 Feb 2011 11:06:56 -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/154306 arm named crashes with signal 11 o arm/154227 arm [geli] using GELI leads to panic on ARM o arm/154189 arm lang/perl5.12 doesn't build 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/149288 arm mail/dovecot causes panic during configure on Sheevapl o arm/134368 arm [patch] nslu2_led driver for the LEDs on the NSLU2 p arm/134338 arm [patch] Lock GPIO accesses on ixp425 8 problems total. From owner-freebsd-arm@FreeBSD.ORG Mon Feb 7 15:38:38 2011 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 25219106567A for ; Mon, 7 Feb 2011 15:38:38 +0000 (UTC) (envelope-from torfinn.ingolfsen@broadpark.no) Received: from thalia-smout.broadpark.no (thalia-smout.broadpark.no [80.202.8.21]) by mx1.freebsd.org (Postfix) with ESMTP id D0C108FC08 for ; Mon, 7 Feb 2011 15:38:37 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from terra-smin.broadpark.no ([80.202.8.13]) by thalia-smout.broadpark.no (Sun Java(tm) System Messaging Server 7u3-15.01 64bit (built Feb 12 2010)) with ESMTP id <0LG9009IZ7GCCF80@thalia-smout.broadpark.no> for freebsd-arm@FreeBSD.org; Mon, 07 Feb 2011 16:38:36 +0100 (CET) Received: from kg-v2.kg4.no ([84.48.120.77]) by terra-smin.broadpark.no (Sun Java(tm) System Messaging Server 7u3-15.01 64bit (built Feb 12 2010)) with SMTP id <0LG90081O7GBUQ21@terra-smin.broadpark.no> for freebsd-arm@FreeBSD.org; Mon, 07 Feb 2011 16:38:35 +0100 (CET) Date: Mon, 07 Feb 2011 16:38:35 +0100 From: Torfinn Ingolfsen To: freebsd-arm@FreeBSD.org Message-id: <20110207163835.41be5884.torfinn.ingolfsen@broadpark.no> In-reply-to: <201102062331.01760.hselasky@c2i.net> References: <20110206181659.869861bf.torfinn.ingolfsen@broadpark.no> <201102061955.38635.freebsd-arm@dino.sk> <20110206231720.e113a196.torfinn.ingolfsen@broadpark.no> <201102062331.01760.hselasky@c2i.net> X-Mailer: Sylpheed 3.0.3 (GTK+ 2.22.1; amd64-portbld-freebsd8.1) X-Face: "t9w2,-X@O^I`jVW\sonI3.,36KBLZE*AL[y9lL[PyFD*r_S:dIL9c[8Y>V42R0"!"yb_zN,f#%.[PYYNq; m"_0v; ~rUM2Yy!zmkh)3&U|u!=T(zyv,MHJv"nDH>OJ`t(@mil461d_B'Uo|'nMwlKe0Mv=kvV?Nh@>Hb<3s_z2jYgZhPb@?Wi^x1a~Hplz1.zH Cc: Subject: Re: FreeBSD on a DockStar - doesn't mount root 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, 07 Feb 2011 15:38:38 -0000 Hello, On Sun, 06 Feb 2011 23:31:01 +0100 Hans Petter Selasky wrote: > On Sunday 06 February 2011 23:17:20 Torfinn Ingolfsen wrote: > > On Sun, 06 Feb 2011 19:55:37 +0100 > > > > Milan Obuch wrote: > > > Did you try typing several dots to test whether some more time to mount > > > root device helps? I would try it, sometimes it helps... Just some more > > > time for background tasks (one dot means one second, It I am not > > > mistaken). > > > > I'm not really sure how it is suposed to be, I tried > > .....ufs:/dev/ufs/kirkwoodroot > > > > and that didn't have any effect. > > Maybe you need to set the scsi delay sysctl, to give the drive more time to > probe. Search the mailing lists :-) Thanks to Milan I now know how to perform the "dot trick" - thanks! :-) It seems to my mountroot prompt is a bit different, it doesn't mention '.' as a "command" for the prompt, and it says it is trying to mount from it: mountroot> ? List of GEOM managed disk devices: Loader variables: vfs.root.mountfrom= vfs.root.mountfrom.options= Manual root filesystem specification: : Mount using filesystem eg. ufs:/dev/da0s1a eg. cd9660:/dev/acd0 This is equivalent to: mount -t cd9660 /dev/acd0 / ? List valid disk boot devices Abort manual input mountroot> . Trying to mount root from . Loader variables: vfs.root.mountfrom= vfs.root.mountfrom.options= Manual root filesystem specification: : Mount using filesystem eg. ufs:/dev/da0s1a eg. cd9660:/dev/acd0 This is equivalent to: mount -t cd9660 /dev/acd0 / ? List valid disk boot devices Abort manual input mountroot> ? List of GEOM managed disk devices: Loader variables: vfs.root.mountfrom= vfs.root.mountfrom.options= Manual root filesystem specification: : Mount using filesystem eg. ufs:/dev/da0s1a eg. cd9660:/dev/acd0 This is equivalent to: mount -t cd9660 /dev/acd0 / ? List valid disk boot devices Abort manual input mountroot> Unfortunately, it doesn't help. I have tried waiting ten minutes - still no devices to boot from. So it seems like this isn't a "delay" type problem. -- Torfinn From owner-freebsd-arm@FreeBSD.ORG Mon Feb 7 15:56:31 2011 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 B99B91065675 for ; Mon, 7 Feb 2011 15:56:31 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from mail.icecube.wisc.edu (trout.icecube.wisc.edu [128.104.255.119]) by mx1.freebsd.org (Postfix) with ESMTP id 900FE8FC21 for ; Mon, 7 Feb 2011 15:56:31 +0000 (UTC) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.icecube.wisc.edu (Postfix) with ESMTP id 40A3658142 for ; Mon, 7 Feb 2011 09:23:18 -0600 (CST) X-Virus-Scanned: amavisd-new at icecube.wisc.edu Received: from mail.icecube.wisc.edu ([127.0.0.1]) by localhost (trout.icecube.wisc.edu [127.0.0.1]) (amavisd-new, port 10030) with ESMTP id 6x+R4e3CtERZ for ; Mon, 7 Feb 2011 09:23:18 -0600 (CST) Received: from wanderer.tachypleus.net (adsl-76-208-68-88.dsl.mdsnwi.sbcglobal.net [76.208.68.88]) by mail.icecube.wisc.edu (Postfix) with ESMTP id E744B58139 for ; Mon, 7 Feb 2011 09:23:17 -0600 (CST) Message-ID: <4D500E65.8060204@freebsd.org> Date: Mon, 07 Feb 2011 09:23:17 -0600 From: Nathan Whitehorn User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.13) Gecko/20110103 Thunderbird/3.1.7 MIME-Version: 1.0 To: freebsd-arm@freebsd.org References: <58CD61A782A34C788A93F8DA363A7DEA@wispskynet> In-Reply-To: <58CD61A782A34C788A93F8DA363A7DEA@wispskynet> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: Avila Network Platform: GW2348-4, GW2348-2, GW2347 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, 07 Feb 2011 15:56:31 -0000 On 02/06/11 07:06, Sky Net wrote: > HELLO > > > I have board Avila GW2348-4 Network Platform There are some slightly out-of-date directions here: http://people.freebsd.org/~sam/README-gateworks The out-of-date bit is that, if you want to use 9-CURRENT, you need to set TARGET=arm TARGET_ARCH=armeb instead of TARGET=arm TARGET_BIG_ENDIAN=true -Nathan From owner-freebsd-arm@FreeBSD.ORG Mon Feb 7 16:13:43 2011 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 86470106566B for ; Mon, 7 Feb 2011 16:13:43 +0000 (UTC) (envelope-from milu@dat.pl) Received: from jab.dat.pl (dat.pl [80.51.155.34]) by mx1.freebsd.org (Postfix) with ESMTP id 417398FC15 for ; Mon, 7 Feb 2011 16:13:43 +0000 (UTC) Received: from jab.dat.pl (jsrv.dat.pl [127.0.0.1]) by jab.dat.pl (Postfix) with ESMTP id CFF7DCD; Mon, 7 Feb 2011 16:57:19 +0100 (CET) X-Virus-Scanned: amavisd-new at dat.pl Received: from jab.dat.pl ([127.0.0.1]) by jab.dat.pl (jab.dat.pl [127.0.0.1]) (amavisd-new, port 10024) with LMTP id JD5e80MSik4d; Mon, 7 Feb 2011 16:57:16 +0100 (CET) Received: from snifi.laptop (unknown [212.69.68.42]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by jab.dat.pl (Postfix) with ESMTPSA id F1446B9; Mon, 7 Feb 2011 16:57:15 +0100 (CET) From: Maciej Milewski To: freebsd-arm@freebsd.org Date: Mon, 7 Feb 2011 16:56:11 +0100 User-Agent: KMail/1.13.5 (FreeBSD/8.2-PRERELEASE; KDE/4.5.5; i386; ; ) References: <20110206181659.869861bf.torfinn.ingolfsen@broadpark.no> <201102062331.01760.hselasky@c2i.net> <20110207163835.41be5884.torfinn.ingolfsen@broadpark.no> In-Reply-To: <20110207163835.41be5884.torfinn.ingolfsen@broadpark.no> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable Message-Id: <201102071656.11633.milu@dat.pl> Cc: Subject: Re: Re: FreeBSD on a DockStar - doesn't mount root 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, 07 Feb 2011 16:13:43 -0000 Monday 07 of February 2011 16:38:35 Torfinn Ingolfsen napisa=B3(a): > Hello, =2E.. > So it seems like this isn't a "delay" type problem. =46rom these dmesg lines you posted in your first mail it looked that is to= o=20 short time for kernel to recognize the usb device. I had similar problems o= n=20 mips RS/RSPRO boards and had to use small patch to make the delay longer. I= =20 admit that I didn't know of kern.cam.boot_delay that time and haven't tried= it=20 on my boards. I don't know the real author of that patch. Additionally I'm booting my board using ufs label this way: ufs:ufs/rootfs diff --git a/sys/kern/vfs_mountroot.c b/sys/kern/vfs_mountroot.c index 496ea70..1956419 100644 =2D-- a/sys/kern/vfs_mountroot.c +++ b/sys/kern/vfs_mountroot.c @@ -87,6 +87,8 @@ __FBSDID("$FreeBSD$"); =20 static int parse_mount(char **); static struct mntarg *parse_mountroot_options(struct mntarg *, const char = *); +static int mount_root_delay =3D 4; +TUNABLE_INT("mount_root_delay", &mount_root_delay); =20 /* * The vnode of the system's root (/ in the filesystem, without chroot @@ -917,13 +919,17 @@ vfs_mountroot_wait(void) PICKUP_GIANT(); mtx_lock(&mountlist_mtx); if (LIST_EMPTY(&root_holds)) { =2D mtx_unlock(&mountlist_mtx); =2D break; + if(0 =3D=3D mount_root_delay--) { + mtx_unlock(&mountlist_mtx); + break; + } } if (ppsratecheck(&lastfail, &curfail, 1)) { printf("Root mount waiting for:"); LIST_FOREACH(h, &root_holds, list) printf(" %s", h->who); + if (LIST_EMPTY(&root_holds)) + printf(" %d=20 secs...",mount_root_delay); printf("\n"); } msleep(&root_holds, &mountlist_mtx, PZERO | PDROP, "roothol= d", Regards, Maciej Milewski From owner-freebsd-arm@FreeBSD.ORG Mon Feb 7 17:03:03 2011 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 0B0BA106564A for ; Mon, 7 Feb 2011 17:03:03 +0000 (UTC) (envelope-from freebsd-arm@dino.sk) Received: from loki.netlab.sk (ns3.netlab.sk [84.245.65.11]) by mx1.freebsd.org (Postfix) with ESMTP id 75F318FC1A for ; Mon, 7 Feb 2011 17:03:01 +0000 (UTC) Received: from door.dino.sk (fw1.dino.sk [84.245.95.252]) (AUTH: PLAIN milan, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by loki.netlab.sk with esmtp; Mon, 07 Feb 2011 18:02:59 +0100 id 00033C0D.4D5025C3.00011CD8 From: Milan Obuch To: freebsd-arm@freebsd.org Date: Mon, 7 Feb 2011 18:02:52 +0100 User-Agent: KMail/1.13.5 (FreeBSD/8.2-PRERELEASE; KDE/4.5.5; i386; ; ) References: <20110206181659.869861bf.torfinn.ingolfsen@broadpark.no> <201102062331.01760.hselasky@c2i.net> <20110207163835.41be5884.torfinn.ingolfsen@broadpark.no> In-Reply-To: <20110207163835.41be5884.torfinn.ingolfsen@broadpark.no> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201102071802.54442.freebsd-arm@dino.sk> Subject: Re: FreeBSD on a DockStar - doesn't mount root 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, 07 Feb 2011 17:03:03 -0000 On Monday 07 February 2011 16:38:35 Torfinn Ingolfsen wrote: [snip] > Thanks to Milan I now know how to perform the "dot trick" - thanks! :-) > It seems to my mountroot prompt is a bit different, it doesn't mention > '.' as a "command" for the prompt, and it says it is trying to mount > from it: > mountroot> ? > > List of GEOM managed disk devices: > > Loader variables: > vfs.root.mountfrom= > vfs.root.mountfrom.options= > > Manual root filesystem specification: > : Mount using filesystem > eg. ufs:/dev/da0s1a > eg. cd9660:/dev/acd0 > This is equivalent to: mount -t cd9660 /dev/acd0 / > > ? List valid disk boot devices > Abort manual input > You did not mention (or I overlooked it) which version your kernel is built from, I am using for both ARM and MIPS devices only 9-CURRENT. In your worklog page it looks like your kernel is 8-SOMETHING based. If that's the case, could you eventually try current? Milan From owner-freebsd-arm@FreeBSD.ORG Mon Feb 7 17:18:25 2011 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 8F5531065670 for ; Mon, 7 Feb 2011 17:18:25 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 30DBB8FC14 for ; Mon, 7 Feb 2011 17:18:25 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.3/8.14.1) with ESMTP id p17HD6Bh060127 for ; Mon, 7 Feb 2011 10:13:06 -0700 (MST) (envelope-from imp@bsdimp.com) Message-ID: <4D502822.2020408@bsdimp.com> Date: Mon, 07 Feb 2011 10:13:06 -0700 From: Warner Losh User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.13) Gecko/20101211 Thunderbird/3.1.7 MIME-Version: 1.0 To: freebsd-arm@FreeBSD.org References: <20110206181659.869861bf.torfinn.ingolfsen@broadpark.no> <201102062331.01760.hselasky@c2i.net> <20110207163835.41be5884.torfinn.ingolfsen@broadpark.no> <201102071656.11633.milu@dat.pl> In-Reply-To: <201102071656.11633.milu@dat.pl> Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 8bit Cc: Subject: Re: FreeBSD on a DockStar - doesn't mount root 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, 07 Feb 2011 17:18:25 -0000 On 02/07/2011 08:56, Maciej Milewski wrote: > Monday 07 of February 2011 16:38:35 Torfinn Ingolfsen napisał(a): >> Hello, > ... >> So it seems like this isn't a "delay" type problem. > From these dmesg lines you posted in your first mail it looked that is too > short time for kernel to recognize the usb device. I had similar problems on > mips RS/RSPRO boards and had to use small patch to make the delay longer. I > admit that I didn't know of kern.cam.boot_delay that time and haven't tried it > on my boards. I've used kern.cam.boot_delay on a RS-PRO board here that I run off the SD card, which is just a da device. Warner > I don't know the real author of that patch. > Additionally I'm booting my board using ufs label this way: > ufs:ufs/rootfs > > > diff --git a/sys/kern/vfs_mountroot.c b/sys/kern/vfs_mountroot.c > index 496ea70..1956419 100644 > --- a/sys/kern/vfs_mountroot.c > +++ b/sys/kern/vfs_mountroot.c > @@ -87,6 +87,8 @@ __FBSDID("$FreeBSD$"); > > static int parse_mount(char **); > static struct mntarg *parse_mountroot_options(struct mntarg *, const char *); > +static int mount_root_delay = 4; > +TUNABLE_INT("mount_root_delay",&mount_root_delay); > > /* > * The vnode of the system's root (/ in the filesystem, without chroot > @@ -917,13 +919,17 @@ vfs_mountroot_wait(void) > PICKUP_GIANT(); > mtx_lock(&mountlist_mtx); > if (LIST_EMPTY(&root_holds)) { > - mtx_unlock(&mountlist_mtx); > - break; > + if(0 == mount_root_delay--) { > + mtx_unlock(&mountlist_mtx); > + break; > + } > } > if (ppsratecheck(&lastfail,&curfail, 1)) { > printf("Root mount waiting for:"); > LIST_FOREACH(h,&root_holds, list) > printf(" %s", h->who); > + if (LIST_EMPTY(&root_holds)) > + printf(" %d > secs...",mount_root_delay); > printf("\n"); > } > msleep(&root_holds,&mountlist_mtx, PZERO | PDROP, "roothold", > > Regards, > Maciej Milewski > _______________________________________________ > 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 Feb 7 18:44:00 2011 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 9F620106564A for ; Mon, 7 Feb 2011 18:44:00 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from asmtpout023.mac.com (asmtpout023.mac.com [17.148.16.98]) by mx1.freebsd.org (Postfix) with ESMTP id 8AA3F8FC12 for ; Mon, 7 Feb 2011 18:44:00 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from sa-nc-common2-131.static.jnpr.net (natint3.juniper.net [66.129.224.36]) by asmtp023.mac.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTPSA id <0LG900MYHG17CU60@asmtp023.mac.com> for arm@freebsd.org; Mon, 07 Feb 2011 10:43:56 -0800 (PST) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.2.15,1.0.148,0.0.0000 definitions=2011-02-07_06:2011-02-07, 2011-02-07, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=4 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=6.0.2-1012030000 definitions=main-1102070089 From: Marcel Moolenaar Date: Mon, 07 Feb 2011 10:43:54 -0800 Message-id: <857AA8D9-5C41-4D80-A3B5-0D29BE051014@mac.com> To: arm@freebsd.org X-Mailer: Apple Mail (2.1082) Cc: Subject: Elimination of cpu_l2cache_* 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: Mon, 07 Feb 2011 18:44:00 -0000 All, I've been reviewing the use of the cpu_l2cache_* functions and found that 1) they're missing from cpu_witch() and 2) they are always used in conjunction with either cpu_idcache_* or cpu_dcache_*. Since most CPU variants define them as null ops, isn't it better to incorporate the functionality of cpu_l2cache_* in cpu_idcache_* and cpu_dcache_* and eliminate them altogether? Any objections to me removing cpu_l2cache_* and therefore changing the semantics of cpu_idcache_* and cpu_dcahce_* to apply to all relevant cache levels? Thanks, -- Marcel Moolenaar xcllnt@mac.com From owner-freebsd-arm@FreeBSD.ORG Mon Feb 7 19:44:31 2011 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 C431F1065672 for ; Mon, 7 Feb 2011 19:44:31 +0000 (UTC) (envelope-from torfinn.ingolfsen@broadpark.no) Received: from thalia-smout.broadpark.no (thalia-smout.broadpark.no [80.202.8.21]) by mx1.freebsd.org (Postfix) with ESMTP id 7D4048FC13 for ; Mon, 7 Feb 2011 19:44:31 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from terra-smin.broadpark.no ([80.202.8.13]) by thalia-smout.broadpark.no (Sun Java(tm) System Messaging Server 7u3-15.01 64bit (built Feb 12 2010)) with ESMTP id <0LG900E14IU52Q50@thalia-smout.broadpark.no> for freebsd-arm@FreeBSD.org; Mon, 07 Feb 2011 20:44:29 +0100 (CET) Received: from kg-v2.kg4.no ([84.48.120.77]) by terra-smin.broadpark.no (Sun Java(tm) System Messaging Server 7u3-15.01 64bit (built Feb 12 2010)) with SMTP id <0LG900811IU5TCB2@terra-smin.broadpark.no> for freebsd-arm@FreeBSD.org; Mon, 07 Feb 2011 20:44:29 +0100 (CET) Date: Mon, 07 Feb 2011 20:44:29 +0100 From: Torfinn Ingolfsen To: freebsd-arm@FreeBSD.org Message-id: <20110207204429.ae2fa012.torfinn.ingolfsen@broadpark.no> In-reply-to: <201102071656.11633.milu@dat.pl> References: <20110206181659.869861bf.torfinn.ingolfsen@broadpark.no> <201102062331.01760.hselasky@c2i.net> <20110207163835.41be5884.torfinn.ingolfsen@broadpark.no> <201102071656.11633.milu@dat.pl> X-Mailer: Sylpheed 3.0.3 (GTK+ 2.22.1; amd64-portbld-freebsd8.1) X-Face: "t9w2,-X@O^I`jVW\sonI3.,36KBLZE*AL[y9lL[PyFD*r_S:dIL9c[8Y>V42R0"!"yb_zN,f#%.[PYYNq; m"_0v; ~rUM2Yy!zmkh)3&U|u!=T(zyv,MHJv"nDH>OJ`t(@mil461d_B'Uo|'nMwlKe0Mv=kvV?Nh@>Hb<3s_z2jYgZhPb@?Wi^x1a~Hplz1.zH Cc: Subject: Re: FreeBSD on a DockStar - doesn't mount root 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, 07 Feb 2011 19:44:31 -0000 On Mon, 07 Feb 2011 16:56:11 +0100 Maciej Milewski wrote: > From these dmesg lines you posted in your first mail it looked that is too > short time for kernel to recognize the usb device. I had similar problems on > mips RS/RSPRO boards and had to use small patch to make the delay longer. I > admit that I didn't know of kern.cam.boot_delay that time and haven't tried it FWIW, I have now tried with kern.cam.boot_delay=10000 in /boot/loader.conf (I also tried the value 20000), but it doesn't boot still. The only difference is that when I enter '?' and press "enter" at the mountroot prompt, the cursor moves to the left on the same line (ie. no line feed), and the nothing more happens. -- Torfinn From owner-freebsd-arm@FreeBSD.ORG Mon Feb 7 19:51:31 2011 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 43D1C1065675 for ; Mon, 7 Feb 2011 19:51:31 +0000 (UTC) (envelope-from torfinn.ingolfsen@broadpark.no) Received: from thalia-smout.broadpark.no (thalia-smout.broadpark.no [80.202.8.21]) by mx1.freebsd.org (Postfix) with ESMTP id F06F98FC08 for ; Mon, 7 Feb 2011 19:51:30 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from terra-smin.broadpark.no ([80.202.8.13]) by thalia-smout.broadpark.no (Sun Java(tm) System Messaging Server 7u3-15.01 64bit (built Feb 12 2010)) with ESMTP id <0LG900EEJJ5N2Q60@thalia-smout.broadpark.no> for freebsd-arm@FreeBSD.org; Mon, 07 Feb 2011 20:51:23 +0100 (CET) Received: from kg-v2.kg4.no ([84.48.120.77]) by terra-smin.broadpark.no (Sun Java(tm) System Messaging Server 7u3-15.01 64bit (built Feb 12 2010)) with SMTP id <0LG900DBCJ5N2R41@terra-smin.broadpark.no> for freebsd-arm@FreeBSD.org; Mon, 07 Feb 2011 20:51:23 +0100 (CET) Date: Mon, 07 Feb 2011 20:51:23 +0100 From: Torfinn Ingolfsen To: freebsd-arm@FreeBSD.org Message-id: <20110207205123.fdfbaf81.torfinn.ingolfsen@broadpark.no> In-reply-to: <201102071802.54442.freebsd-arm@dino.sk> References: <20110206181659.869861bf.torfinn.ingolfsen@broadpark.no> <201102062331.01760.hselasky@c2i.net> <20110207163835.41be5884.torfinn.ingolfsen@broadpark.no> <201102071802.54442.freebsd-arm@dino.sk> X-Mailer: Sylpheed 3.0.3 (GTK+ 2.22.1; amd64-portbld-freebsd8.1) X-Face: "t9w2,-X@O^I`jVW\sonI3.,36KBLZE*AL[y9lL[PyFD*r_S:dIL9c[8Y>V42R0"!"yb_zN,f#%.[PYYNq; m"_0v; ~rUM2Yy!zmkh)3&U|u!=T(zyv,MHJv"nDH>OJ`t(@mil461d_B'Uo|'nMwlKe0Mv=kvV?Nh@>Hb<3s_z2jYgZhPb@?Wi^x1a~Hplz1.zH Cc: Subject: Re: FreeBSD on a DockStar - doesn't mount root 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, 07 Feb 2011 19:51:31 -0000 On Mon, 07 Feb 2011 18:02:52 +0100 Milan Obuch wrote: > You did not mention (or I overlooked it) which version your kernel is built > from, I am using for both ARM and MIPS devices only 9-CURRENT. In your worklog > page it looks like your kernel is 8-SOMETHING based. If that's the case, could > you eventually try current? I took the easy way - I didn't build anything, I used the kernel and userland from here: http://cooltrainer.org/projects/freebsd-kirkwood/distribution/ >From the dmesg output, I see that it is: FreeBSD 8.1-RELEASE-p1 #3: Sun Sep 26 21:26:45 EDT 2010 I'm pretty sure I mentioned that in my first posting. Anyway, it is all written down in my worklog here: http://sites.google.com/site/tingox/seagate_dockstar_freebsd As for trying something newer, sure - it depends on how easy I can get or build a newer kernel / userland. -- Torfinn From owner-freebsd-arm@FreeBSD.ORG Mon Feb 7 20:06:29 2011 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 4D941106564A for ; Mon, 7 Feb 2011 20:06:29 +0000 (UTC) (envelope-from marktinguely@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 114F38FC19 for ; Mon, 7 Feb 2011 20:06:28 +0000 (UTC) Received: by iwn39 with SMTP id 39so5013085iwn.13 for ; Mon, 07 Feb 2011 12:06:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=3ERj5q4OhZVMy5vmBsElr5IjX8t2TGFvfC0UVk2hTwU=; b=wDc5EoCJapGB4hsh1Fr0mOOKaS5zhgT8abTvHeDb+o67yfqmr0rD0w1zXiwmYp1/qA j6773c2MGnHGKqNbITEUnMRSsywRmeyggka0o34QZg3PEvLRLoUXf/0lj+nDBJBfsjYt cTaZsFV7lSDgL0aBNxnG7DNYh0lsQ94AXnSk4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; b=F0y8O4DWDAN975135lrHSZlMbF9PZSpbH5L7UsfTc8jTMVZG6/NxpT4YU6cvzKzqB7 dzZnlYCT4WGKNb7x9Cc0XTy/Rp9oPSSbMNj3zWK/pJIUNCxsR6JPIZ6efmcBowEJRNXc wp9nU424AjDEhY5a+xp8UcDFbjE+7SQztgG3E= Received: by 10.42.174.71 with SMTP id u7mr5794420icz.62.1297109188501; Mon, 07 Feb 2011 12:06:28 -0800 (PST) Received: from [192.168.1.101] (c-24-245-26-12.hsd1.mn.comcast.net [24.245.26.12]) by mx.google.com with ESMTPS id c4sm3653492ict.19.2011.02.07.12.06.12 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 07 Feb 2011 12:06:17 -0800 (PST) Message-ID: <4D5050B3.4070608@gmail.com> Date: Mon, 07 Feb 2011 14:06:11 -0600 From: Mark Tinguely User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: freebsd-arm@freebsd.org References: <857AA8D9-5C41-4D80-A3B5-0D29BE051014@mac.com> In-Reply-To: <857AA8D9-5C41-4D80-A3B5-0D29BE051014@mac.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: Elimination of cpu_l2cache_* 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: Mon, 07 Feb 2011 20:06:29 -0000 On 2/7/2011 12:43 PM, Marcel Moolenaar wrote: > All, > > I've been reviewing the use of the cpu_l2cache_* functions and found > that 1) they're missing from cpu_witch() and 2) they are always used > in conjunction with either cpu_idcache_* or cpu_dcache_*. > > Since most CPU variants define them as null ops, isn't it better to > incorporate the functionality of cpu_l2cache_* in cpu_idcache_* and > cpu_dcache_* and eliminate them altogether? > > Any objections to me removing cpu_l2cache_* and therefore changing > the semantics of cpu_idcache_* and cpu_dcahce_* to apply to all > relevant cache levels? > > Thanks, It was pointed out to me that the level two cache operation were removed from the context switch on purpose, for performance reasons. I think this exception is why we still have both a level one and level two cache operation definitions. I proposed the senerio that the Sheeva cluster IO filesystem corruption problem is related to level two caches not being written back and removed upon context switch. Assuming we want to keep the performance gain by not performing the level two cache operations when we perform a context switch, and since I believe that the Sheeva has PIPT level two caches, I have a proposed fix to pmap_idcache_wdinv_range() that maps the page to a local KVA and doing the appropriate level two cache operation when needed. --- In ARMv6 and ARMv7, the inner (level one) caches are PIPT, and all these cache operations go away with the exception of the sync area of the busdma routine. --Mark Tinguely From owner-freebsd-arm@FreeBSD.ORG Mon Feb 7 20:34:39 2011 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 2CEE0106564A for ; Mon, 7 Feb 2011 20:34:39 +0000 (UTC) (envelope-from torfinn.ingolfsen@broadpark.no) Received: from thalia-smout.broadpark.no (thalia-smout.broadpark.no [80.202.8.21]) by mx1.freebsd.org (Postfix) with ESMTP id D7D6E8FC14 for ; Mon, 7 Feb 2011 20:34:38 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from terra-smin.broadpark.no ([80.202.8.13]) by thalia-smout.broadpark.no (Sun Java(tm) System Messaging Server 7u3-15.01 64bit (built Feb 12 2010)) with ESMTP id <0LG900EKNL5P2QD0@thalia-smout.broadpark.no> for freebsd-arm@FreeBSD.org; Mon, 07 Feb 2011 21:34:37 +0100 (CET) Received: from kg-v2.kg4.no ([84.48.120.77]) by terra-smin.broadpark.no (Sun Java(tm) System Messaging Server 7u3-15.01 64bit (built Feb 12 2010)) with SMTP id <0LG900E1EL5PO7P0@terra-smin.broadpark.no> for freebsd-arm@FreeBSD.org; Mon, 07 Feb 2011 21:34:37 +0100 (CET) Date: Mon, 07 Feb 2011 21:34:37 +0100 From: Torfinn Ingolfsen To: freebsd-arm@FreeBSD.org Message-id: <20110207213437.9839d476.torfinn.ingolfsen@broadpark.no> In-reply-to: <20110207204429.ae2fa012.torfinn.ingolfsen@broadpark.no> References: <20110206181659.869861bf.torfinn.ingolfsen@broadpark.no> <201102062331.01760.hselasky@c2i.net> <20110207163835.41be5884.torfinn.ingolfsen@broadpark.no> <201102071656.11633.milu@dat.pl> <20110207204429.ae2fa012.torfinn.ingolfsen@broadpark.no> X-Mailer: Sylpheed 3.0.3 (GTK+ 2.22.1; amd64-portbld-freebsd8.1) X-Face: "t9w2,-X@O^I`jVW\sonI3.,36KBLZE*AL[y9lL[PyFD*r_S:dIL9c[8Y>V42R0"!"yb_zN,f#%.[PYYNq; m"_0v; ~rUM2Yy!zmkh)3&U|u!=T(zyv,MHJv"nDH>OJ`t(@mil461d_B'Uo|'nMwlKe0Mv=kvV?Nh@>Hb<3s_z2jYgZhPb@?Wi^x1a~Hplz1.zH Cc: Subject: Re: FreeBSD on a DockStar - doesn't mount root 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, 07 Feb 2011 20:34:39 -0000 Another update: On Mon, 07 Feb 2011 20:44:29 +0100 Torfinn Ingolfsen wrote: > FWIW, I have now tried with kern.cam.boot_delay=10000 > in /boot/loader.conf (I also tried the value 20000), but it doesn't > boot still. I have now tried with kern.cam.scsi_delay=10000 (also tried the value 20000) instead of kern.cam.boot_delay in /boot/loader.conf Doesn't make the Dockstar boot, and doesn't make it hang. -- Torfinn From owner-freebsd-arm@FreeBSD.ORG Mon Feb 7 21:38:14 2011 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 684971065674 for ; Mon, 7 Feb 2011 21:38:14 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from asmtpout021.mac.com (asmtpout021.mac.com [17.148.16.96]) by mx1.freebsd.org (Postfix) with ESMTP id 4E5158FC12 for ; Mon, 7 Feb 2011 21:38:14 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from sa-nc-common2-131.static.jnpr.net (natint3.juniper.net [66.129.224.36]) by asmtp021.mac.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTPSA id <0LG9002O2LAMEJH0@asmtp021.mac.com> for freebsd-arm@freebsd.org; Mon, 07 Feb 2011 12:37:35 -0800 (PST) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.2.15,1.0.148,0.0.0000 definitions=2011-02-07_06:2011-02-07, 2011-02-07, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=2 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=6.0.2-1012030000 definitions=main-1102070104 From: Marcel Moolenaar In-reply-to: <4D5050B3.4070608@gmail.com> Date: Mon, 07 Feb 2011 12:37:33 -0800 Message-id: <4A878FC3-C011-4E40-8B36-71E36B4C4A11@mac.com> References: <857AA8D9-5C41-4D80-A3B5-0D29BE051014@mac.com> <4D5050B3.4070608@gmail.com> To: Mark Tinguely X-Mailer: Apple Mail (2.1082) Cc: freebsd-arm@freebsd.org Subject: Re: Elimination of cpu_l2cache_* 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: Mon, 07 Feb 2011 21:38:14 -0000 On Feb 7, 2011, at 12:06 PM, Mark Tinguely wrote: > On 2/7/2011 12:43 PM, Marcel Moolenaar wrote: >> All, >> >> I've been reviewing the use of the cpu_l2cache_* functions and found >> that 1) they're missing from cpu_witch() and 2) they are always used >> in conjunction with either cpu_idcache_* or cpu_dcache_*. >> >> Since most CPU variants define them as null ops, isn't it better to >> incorporate the functionality of cpu_l2cache_* in cpu_idcache_* and >> cpu_dcache_* and eliminate them altogether? >> >> Any objections to me removing cpu_l2cache_* and therefore changing >> the semantics of cpu_idcache_* and cpu_dcahce_* to apply to all >> relevant cache levels? >> >> Thanks, > > It was pointed out to me that the level two cache operation were removed from the context switch on purpose, for performance reasons. I think this exception is why we still have both a level one and level two cache operation definitions. > > I proposed the senerio that the Sheeva cluster IO filesystem corruption problem is related to level two caches not being written back and removed upon context switch. Assuming we want to keep the performance gain by not performing the level two cache operations when we perform a context switch, and since I believe that the Sheeva has PIPT level two caches, I have a proposed fix to pmap_idcache_wdinv_range() that maps the page to a local KVA and doing the appropriate level two cache operation when needed. > --- > In ARMv6 and ARMv7, the inner (level one) caches are PIPT, and all these cache operations go away with the exception of the sync area of the busdma routine. Hi Mark, Yes, the L2 cache on the Sheeva is PIPT, and I think it's safe to remove the the L2 cache operations from the context switch. However, why do we have L2 cache operations everywhere else when we only need to worry about it for DMA and when synchronizing the I-cache in that case right? -- Marcel Moolenaar xcllnt@mac.com From owner-freebsd-arm@FreeBSD.ORG Mon Feb 7 21:38:15 2011 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 A6E0F1065670 for ; Mon, 7 Feb 2011 21:38:15 +0000 (UTC) (envelope-from marktinguely@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 64FC28FC13 for ; Mon, 7 Feb 2011 21:38:15 +0000 (UTC) Received: by iyb26 with SMTP id 26so5102269iyb.13 for ; Mon, 07 Feb 2011 13:38:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=/fzeCAoLBGuSm9WzhEDLP0UBYjJJE4gEUE7nM9mya48=; b=fgw65xVIGs2moD0DFnYw8/xrwrgOoNVKWvOkHTVoKGE6dqb7GVfD+9JZfEUGu4YMub wmuEwEOxZKj8sCTFG+OWv9Vz7zC0x98c1ZYltzOA354CfYqlSWKtjdvfX1DXULMn9M70 loyLk0GeK1mT81BblibFdyKevfXqstGcGaHyg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=M1qXJqbQ5XhpyoAZOxAlRm7TnZ2tUHMuGYijimvGK531S04QVVFSzVcgLKaI5OFqmN 4IdIhJQzfX1muqu1IU4XcgEOPEp4m+O4ro8gxZR652iY/rdvucPZ+9LuJh/0gu8JKfMD IXuddKyS2kXC2qjepLU0oE91NINhVArzDqr2Y= Received: by 10.42.220.8 with SMTP id hw8mr5300730icb.111.1297114694367; Mon, 07 Feb 2011 13:38:14 -0800 (PST) Received: from [192.168.1.101] (c-24-245-26-12.hsd1.mn.comcast.net [24.245.26.12]) by mx.google.com with ESMTPS id u9sm4124468ibe.20.2011.02.07.13.38.13 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 07 Feb 2011 13:38:13 -0800 (PST) Message-ID: <4D506642.5000701@gmail.com> Date: Mon, 07 Feb 2011 15:38:10 -0600 From: Mark Tinguely User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Marcel Moolenaar References: <857AA8D9-5C41-4D80-A3B5-0D29BE051014@mac.com> <4D5050B3.4070608@gmail.com> <4A878FC3-C011-4E40-8B36-71E36B4C4A11@mac.com> In-Reply-To: <4A878FC3-C011-4E40-8B36-71E36B4C4A11@mac.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-arm@freebsd.org Subject: Re: Elimination of cpu_l2cache_* 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: Mon, 07 Feb 2011 21:38:15 -0000 On 2/7/2011 2:37 PM, Marcel Moolenaar wrote: > On Feb 7, 2011, at 12:06 PM, Mark Tinguely wrote: > >> On 2/7/2011 12:43 PM, Marcel Moolenaar wrote: >>> All, >>> >>> I've been reviewing the use of the cpu_l2cache_* functions and found >>> that 1) they're missing from cpu_witch() and 2) they are always used >>> in conjunction with either cpu_idcache_* or cpu_dcache_*. >>> >>> Since most CPU variants define them as null ops, isn't it better to >>> incorporate the functionality of cpu_l2cache_* in cpu_idcache_* and >>> cpu_dcache_* and eliminate them altogether? >>> >>> Any objections to me removing cpu_l2cache_* and therefore changing >>> the semantics of cpu_idcache_* and cpu_dcahce_* to apply to all >>> relevant cache levels? >>> >>> Thanks, >> It was pointed out to me that the level two cache operation were removed from the context switch on purpose, for performance reasons. I think this exception is why we still have both a level one and level two cache operation definitions. >> >> I proposed the senerio that the Sheeva cluster IO filesystem corruption problem is related to level two caches not being written back and removed upon context switch. Assuming we want to keep the performance gain by not performing the level two cache operations when we perform a context switch, and since I believe that the Sheeva has PIPT level two caches, I have a proposed fix to pmap_idcache_wdinv_range() that maps the page to a local KVA and doing the appropriate level two cache operation when needed. >> --- >> In ARMv6 and ARMv7, the inner (level one) caches are PIPT, and all these cache operations go away with the exception of the sync area of the busdma routine. > Hi Mark, > > Yes, the L2 cache on the Sheeva is PIPT, and I think it's safe to remove the > the L2 cache operations from the context switch. However, why do we have L2 > cache operations everywhere else when we only need to worry about it for DMA > and when synchronizing the I-cache in that case right? > Yes, dma sync would be the only place we need to do level-two PIPT cache operations. The new busdma routines with a "sync list" could handle this easily. The "sync list" can be made to remember which pages have an active level-lone cache mapping and and which pages did not. Obviously, the dma sync routine will perform the appropriate level-one cache operations on the pages that were marked as having active mappings and the level-two operations would be done in all cases. If I remember correctly, I played with this idea at one time, but threw it away. --Mark. I From owner-freebsd-arm@FreeBSD.ORG Mon Feb 7 22:16:02 2011 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 8A3FA106566B for ; Mon, 7 Feb 2011 22:16:02 +0000 (UTC) (envelope-from marktinguely@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 49C708FC15 for ; Mon, 7 Feb 2011 22:16:02 +0000 (UTC) Received: by iyb26 with SMTP id 26so5137911iyb.13 for ; Mon, 07 Feb 2011 14:16:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=ByjsUXxZCBlODj2+ju5oBurrhBZm1FOWaVRClW85DvA=; b=OmHmBgLa8ipvCwFgvetM9jHsRQmdpXMHkggL38GiTkEXn6yX8DPHDMIaXGa2IndRna +7WT+cZSdd0kldsCZ3sbhcNX48QpPnHnMjrj72jbz3selCIRO8qVntQ+jFIIGkgdCBmj O4RKkbGnZtkTmERJ7sSJR61RNlES9ZdjVbNSM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=e84v5e96Apo4UWGgaI2ls8psTPcJKtvGEw1d8NIwef0QYfns3xzMG9CPXSJFNoZgGS hweseLJbVgKbgGE3HdtxBexZoBFQMV0uPiruze3Heap1Br8hBb7df8uOuRZaOTJU5IfD aKba+iohGVJVKe2YnDEQ+Oo26dRVQldd6N/8M= Received: by 10.42.217.200 with SMTP id hn8mr258065icb.69.1297116961252; Mon, 07 Feb 2011 14:16:01 -0800 (PST) Received: from [192.168.1.101] (c-24-245-26-12.hsd1.mn.comcast.net [24.245.26.12]) by mx.google.com with ESMTPS id z4sm4144521ibg.7.2011.02.07.14.15.58 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 07 Feb 2011 14:15:59 -0800 (PST) Message-ID: <4D506F1C.5090004@gmail.com> Date: Mon, 07 Feb 2011 16:15:56 -0600 From: Mark Tinguely User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Marcel Moolenaar References: <857AA8D9-5C41-4D80-A3B5-0D29BE051014@mac.com> <4D5050B3.4070608@gmail.com> <4A878FC3-C011-4E40-8B36-71E36B4C4A11@mac.com> <4D506642.5000701@gmail.com> In-Reply-To: <4D506642.5000701@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-arm@freebsd.org Subject: Re: Elimination of cpu_l2cache_* 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: Mon, 07 Feb 2011 22:16:02 -0000 On 2/7/2011 3:38 PM, Mark Tinguely wrote > If I remember correctly, I played with this idea at one time, but > threw it away. > > --Mark. Oops, it is still my main ARMv5 implementation: http://www.tinguelys.info/mark/freebsd/busdma_machdepV5.c There are a few undocumented deviations in this file: allocated buffers are not uncached. allocated buffers are cache aligned. does not sync post reads. there is a define to re-enable this feature. --Mark From owner-freebsd-arm@FreeBSD.ORG Tue Feb 8 13:39:48 2011 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 8F3531065672 for ; Tue, 8 Feb 2011 13:39:48 +0000 (UTC) (envelope-from milu@dat.pl) Received: from jab.dat.pl (dat.pl [80.51.155.34]) by mx1.freebsd.org (Postfix) with ESMTP id 48E2C8FC0C for ; Tue, 8 Feb 2011 13:39:47 +0000 (UTC) Received: from jab.dat.pl (jsrv.dat.pl [127.0.0.1]) by jab.dat.pl (Postfix) with ESMTP id BE21E62; Tue, 8 Feb 2011 14:39:46 +0100 (CET) X-Virus-Scanned: amavisd-new at dat.pl Received: from jab.dat.pl ([127.0.0.1]) by jab.dat.pl (jab.dat.pl [127.0.0.1]) (amavisd-new, port 10024) with LMTP id AJyVTWzHiMBW; Tue, 8 Feb 2011 14:39:40 +0100 (CET) Received: from snifi.localnet (unknown [212.69.68.42]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by jab.dat.pl (Postfix) with ESMTPSA id 9E69056; Tue, 8 Feb 2011 14:39:40 +0100 (CET) From: Maciej Milewski To: freebsd-arm@freebsd.org Date: Tue, 8 Feb 2011 14:39:46 +0100 User-Agent: KMail/1.13.6 (Linux/2.6.37-ARCH; KDE/4.6.0; x86_64; ; ) References: <20110206181659.869861bf.torfinn.ingolfsen@broadpark.no> <201102071656.11633.milu@dat.pl> <4D502822.2020408@bsdimp.com> In-Reply-To: <4D502822.2020408@bsdimp.com> X-KMail-Markup: true MIME-Version: 1.0 Message-Id: <201102081439.47302.milu@dat.pl> Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: Re: FreeBSD on a DockStar - doesn't mount root 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, 08 Feb 2011 13:39:48 -0000 Dnia poniedzia=B3ek, 7 lutego 2011 o 18:13:06 Warner Losh napisa=B3(a): > I've used kern.cam.boot_delay on a RS-PRO board here that I run off the > SD card, which is just a da device. >=20 > Warner Warner, How do you pass it to the kernel? via redboot's exec -c "kern.cam.boot_delay=3D" ? Maciej From owner-freebsd-arm@FreeBSD.ORG Wed Feb 9 09:56:05 2011 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 B7DAD106566B for ; Wed, 9 Feb 2011 09:56:05 +0000 (UTC) (envelope-from mlfbsd@kanar.ci0.org) Received: from kanar.ci0.org (unknown [IPv6:2a01:e0b:1:50:40:63ff:feea:93a]) by mx1.freebsd.org (Postfix) with ESMTP id 52B3A8FC08 for ; Wed, 9 Feb 2011 09:56:05 +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 p199uUfU057373; Wed, 9 Feb 2011 10:56:30 +0100 (CET) (envelope-from mlfbsd@kanar.ci0.org) Received: (from mlfbsd@localhost) by kanar.ci0.org (8.14.2/8.14.3/Submit) id p199uUU7057372; Wed, 9 Feb 2011 10:56:30 +0100 (CET) (envelope-from mlfbsd) Date: Wed, 9 Feb 2011 10:56:30 +0100 From: Olivier Houchard To: Marcel Moolenaar Message-ID: <20110209095630.GA57320@ci0.org> References: <857AA8D9-5C41-4D80-A3B5-0D29BE051014@mac.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <857AA8D9-5C41-4D80-A3B5-0D29BE051014@mac.com> User-Agent: Mutt/1.4.2.1i Cc: arm@freebsd.org Subject: Re: Elimination of cpu_l2cache_* 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: Wed, 09 Feb 2011 09:56:05 -0000 Hi Marcel, On Mon, Feb 07, 2011 at 10:43:54AM -0800, Marcel Moolenaar wrote: > All, > > I've been reviewing the use of the cpu_l2cache_* functions and found > that 1) they're missing from cpu_witch() and 2) they are always used > in conjunction with either cpu_idcache_* or cpu_dcache_*. > > Since most CPU variants define them as null ops, isn't it better to > incorporate the functionality of cpu_l2cache_* in cpu_idcache_* and > cpu_dcache_* and eliminate them altogether? > > Any objections to me removing cpu_l2cache_* and therefore changing > the semantics of cpu_idcache_* and cpu_dcahce_* to apply to all > relevant cache levels? > I chose to make the l2cache functions separate from the [i]dcache functions because there's a number of cases where L1 cache flush was needed, but not L2, and that would be a performance penalty to do both. Also, more CPU variants define them as null ops now, but most new arm cpus come with a L2 cache,, so we need to think about it carefully. Regards, Olivier From owner-freebsd-arm@FreeBSD.ORG Wed Feb 9 16:25:58 2011 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 B76B11065672 for ; Wed, 9 Feb 2011 16:25:58 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from asmtpout023.mac.com (asmtpout023.mac.com [17.148.16.98]) by mx1.freebsd.org (Postfix) with ESMTP id 9CDD78FC08 for ; Wed, 9 Feb 2011 16:25:58 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from [192.168.22.188] (ns-visitor-nsrp.juniper.net [208.223.208.242]) by asmtp023.mac.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTPSA id <0LGC00M2LYYNO940@asmtp023.mac.com> for arm@freebsd.org; Wed, 09 Feb 2011 08:25:36 -0800 (PST) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.2.15,1.0.148,0.0.0000 definitions=2011-02-09_06:2011-02-09, 2011-02-09, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=6.0.2-1012030000 definitions=main-1102090085 From: Marcel Moolenaar In-reply-to: <20110209095630.GA57320@ci0.org> Date: Wed, 09 Feb 2011 08:25:35 -0800 Message-id: References: <857AA8D9-5C41-4D80-A3B5-0D29BE051014@mac.com> <20110209095630.GA57320@ci0.org> To: Olivier Houchard X-Mailer: Apple Mail (2.1082) Cc: arm@freebsd.org Subject: Re: Elimination of cpu_l2cache_* 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: Wed, 09 Feb 2011 16:25:58 -0000 On Feb 9, 2011, at 1:56 AM, Olivier Houchard wrote: > Hi Marcel, > > On Mon, Feb 07, 2011 at 10:43:54AM -0800, Marcel Moolenaar wrote: >> All, >> >> I've been reviewing the use of the cpu_l2cache_* functions and found >> that 1) they're missing from cpu_witch() and 2) they are always used >> in conjunction with either cpu_idcache_* or cpu_dcache_*. >> >> Since most CPU variants define them as null ops, isn't it better to >> incorporate the functionality of cpu_l2cache_* in cpu_idcache_* and >> cpu_dcache_* and eliminate them altogether? >> >> Any objections to me removing cpu_l2cache_* and therefore changing >> the semantics of cpu_idcache_* and cpu_dcahce_* to apply to all >> relevant cache levels? Hi Olivier, good to hear from you, > I chose to make the l2cache functions separate from the [i]dcache functions > because there's a number of cases where L1 cache flush was needed, but not L2, > and that would be a performance penalty to do both. I'll take it from this that the L2 is PIPT for the Xscale core 3 as well, right? > Also, more CPU variants define them as null ops now, but most new arm cpus > come with a L2 cache,, so we need to think about it carefully. Agreed. If the L2 cache is PIPT, then we should not do tie L1 & L2 together and I'd like to change the code to remove the L2 cache operations from most places where we have them now. What I'm thinking about is the following: introduce pmap_switch(), as we have it on ia64. This function is called from cpu_switch to replace the existing active pmap with a new one. In pmap_switch() we flush the VIVT caches *IFF* the new pmap is different from the old (=currently active) pmap. Consequently, we're not going to flush the VIVT caches when we switch between kernel threads, nor do we flush the caches when we switch between threads in the same process. In all other cases we'll flush the VIVT caches. pmap_switch() is also called when a pmap interface function gets a pmap to work on. The interface function switches the pmap, (if applicable) which may or may not force a VIVT cache operation. The pmap interface function does it's work, after which it switches back to the pmap that was active on entry to the function. This then could also trigger VIVT cache operations. In any case: I'm thinking that this removes most of the explicit calls to the cache functions while still guaranteing coherency. I need to look into the aliasing case to see how that is handled. I have some ideas for that too... Thoughts? -- Marcel Moolenaar xcllnt@mac.com From owner-freebsd-arm@FreeBSD.ORG Wed Feb 9 17:59:11 2011 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 8CAE91065679 for ; Wed, 9 Feb 2011 17:59:11 +0000 (UTC) (envelope-from marktinguely@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 4C9558FC14 for ; Wed, 9 Feb 2011 17:59:10 +0000 (UTC) Received: by iwn39 with SMTP id 39so387961iwn.13 for ; Wed, 09 Feb 2011 09:59:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=mu6n5o7u9gkhds0/CWBIvr1DG+SNCGOPMkYMMHwi0SY=; b=KsR5Se7qtbHYYEzsDCUO/optXVKlv+xeII2bBujProkYAR1YA2oO3QN5fBEl2ifcrX v9moHgqkg11QKIfaqmwGCoo5k59Na2PnGk1ZiwU/mXNuhYfyyavV04BO5tfYdXy1avb7 GTnRVEo89NtHmsdsG+2d6wMutK8fOTPZtzQ/M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=VZR/p7S1QvUnsBSCTBZbw4gqCtJhAagHxI6HthIu9SisiMCwwkGK9OJtBHvOrJLfbY BlZzTKMa290JWahgz/ebmJNInRrzJMjHLkhwiluDpDcwj/+oHRfty4Id7TIDylu9YmBS V+TceN4WKAJudJo15TnY/EIDhl8W1dC7vJ2EE= Received: by 10.42.223.197 with SMTP id il5mr12374758icb.48.1297272867697; Wed, 09 Feb 2011 09:34:27 -0800 (PST) Received: from [192.168.1.101] (c-24-245-26-12.hsd1.mn.comcast.net [24.245.26.12]) by mx.google.com with ESMTPS id i2sm379996icv.15.2011.02.09.09.34.24 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 09 Feb 2011 09:34:25 -0800 (PST) Message-ID: <4D52D01D.7060204@gmail.com> Date: Wed, 09 Feb 2011 11:34:21 -0600 From: Mark Tinguely User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Marcel Moolenaar References: <857AA8D9-5C41-4D80-A3B5-0D29BE051014@mac.com> <20110209095630.GA57320@ci0.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: arm@freebsd.org Subject: Re: Elimination of cpu_l2cache_* 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: Wed, 09 Feb 2011 17:59:11 -0000 On 2/9/2011 10:25 AM, Marcel Moolenaar wrote: > On Feb 9, 2011, at 1:56 AM, Olivier Houchard wrote: > >> Hi Marcel, >> >> On Mon, Feb 07, 2011 at 10:43:54AM -0800, Marcel Moolenaar wrote: >>> All, >>> >>> I've been reviewing the use of the cpu_l2cache_* functions and found >>> that 1) they're missing from cpu_witch() and 2) they are always used >>> in conjunction with either cpu_idcache_* or cpu_dcache_*. >>> >>> Since most CPU variants define them as null ops, isn't it better to >>> incorporate the functionality of cpu_l2cache_* in cpu_idcache_* and >>> cpu_dcache_* and eliminate them altogether? >>> >>> Any objections to me removing cpu_l2cache_* and therefore changing >>> the semantics of cpu_idcache_* and cpu_dcahce_* to apply to all >>> relevant cache levels? > Hi Olivier, good to hear from you, > >> I chose to make the l2cache functions separate from the [i]dcache functions >> because there's a number of cases where L1 cache flush was needed, but not L2, >> and that would be a performance penalty to do both. > I'll take it from this that the L2 is PIPT for the Xscale core 3 > as well, right? > >> Also, more CPU variants define them as null ops now, but most new arm cpus >> come with a L2 cache,, so we need to think about it carefully. > Agreed. If the L2 cache is PIPT, then we should not do tie L1& L2 > together and I'd like to change the code to remove the L2 cache > operations from most places where we have them now. My point is the L2 caches better be PIPT. If the L2 cache are virtual indexed and we do not flush them on context change, then we could have multiple copies in the L2 cache when we share a page and the width of the level 2 cache is larger than a page. It only make sense from the hardware design side to make the L2 cache PIPT. > What I'm thinking about is the following: introduce pmap_switch(), > as we have it on ia64. This function is called from cpu_switch to > replace the existing active pmap with a new one. In pmap_switch() > we flush the VIVT caches *IFF* the new pmap is different from the > old (=currently active) pmap. Consequently, we're not going to > flush the VIVT caches when we switch between kernel threads, nor > do we flush the caches when we switch between threads in the > same process. In all other cases we'll flush the VIVT caches. > > pmap_switch() is also called when a pmap interface function gets > a pmap to work on. The interface function switches the pmap, (if > applicable) which may or may not force a VIVT cache operation. > The pmap interface function does it's work, after which it switches > back to the pmap that was active on entry to the function. This > then could also trigger VIVT cache operations. > > In any case: I'm thinking that this removes most of the explicit > calls to the cache functions while still guaranteing coherency. > > I need to look into the aliasing case to see how that is handled. > I have some ideas for that too... > > Thoughts? > There are places we can remove redundant cache operations; pmap_qenter() comes to mind. A lot of the cache operations outside of a context switch occur because we share a page within the same memory map (I think that is what you mean by the aliasing case), we turn access or writing off, and for dma. For VIVT caches, I can't see these operations going away. The page copying and zeroing are other examples and it seems like they need cache operations. --Mark. From owner-freebsd-arm@FreeBSD.ORG Wed Feb 9 19:28:05 2011 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 EFF6D106564A for ; Wed, 9 Feb 2011 19:28:05 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from asmtpout027.mac.com (asmtpout027.mac.com [17.148.16.102]) by mx1.freebsd.org (Postfix) with ESMTP id D4F598FC12 for ; Wed, 9 Feb 2011 19:28:05 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from sa-nc-common2-131.static.jnpr.net (natint3.juniper.net [66.129.224.36]) by asmtp027.mac.com (Oracle Communications Messaging Exchange Server 7u4-18.01 64bit (built Jul 15 2010)) with ESMTPSA id <0LGD005MP7EP9M30@asmtp027.mac.com> for arm@freebsd.org; Wed, 09 Feb 2011 11:28:03 -0800 (PST) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.2.15,1.0.148,0.0.0000 definitions=2011-02-09_06:2011-02-09, 2011-02-09, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=2 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=6.0.2-1012030000 definitions=main-1102090118 From: Marcel Moolenaar In-reply-to: <4D52D01D.7060204@gmail.com> Date: Wed, 09 Feb 2011 11:28:00 -0800 Message-id: <5DBD21BB-5C7A-4389-BF28-D508B06DB656@mac.com> References: <857AA8D9-5C41-4D80-A3B5-0D29BE051014@mac.com> <20110209095630.GA57320@ci0.org> <4D52D01D.7060204@gmail.com> To: Mark Tinguely X-Mailer: Apple Mail (2.1082) Cc: arm@freebsd.org Subject: Re: Elimination of cpu_l2cache_* 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: Wed, 09 Feb 2011 19:28:06 -0000 On Feb 9, 2011, at 9:34 AM, Mark Tinguely wrote: > On 2/9/2011 10:25 AM, Marcel Moolenaar wrote: >> On Feb 9, 2011, at 1:56 AM, Olivier Houchard wrote: >> >>> Hi Marcel, >>> >>> On Mon, Feb 07, 2011 at 10:43:54AM -0800, Marcel Moolenaar wrote: >>>> All, >>>> >>>> I've been reviewing the use of the cpu_l2cache_* functions and found >>>> that 1) they're missing from cpu_witch() and 2) they are always used >>>> in conjunction with either cpu_idcache_* or cpu_dcache_*. >>>> >>>> Since most CPU variants define them as null ops, isn't it better to >>>> incorporate the functionality of cpu_l2cache_* in cpu_idcache_* and >>>> cpu_dcache_* and eliminate them altogether? >>>> >>>> Any objections to me removing cpu_l2cache_* and therefore changing >>>> the semantics of cpu_idcache_* and cpu_dcahce_* to apply to all >>>> relevant cache levels? >> Hi Olivier, good to hear from you, >> >>> I chose to make the l2cache functions separate from the [i]dcache functions >>> because there's a number of cases where L1 cache flush was needed, but not L2, >>> and that would be a performance penalty to do both. >> I'll take it from this that the L2 is PIPT for the Xscale core 3 >> as well, right? >> >>> Also, more CPU variants define them as null ops now, but most new arm cpus >>> come with a L2 cache,, so we need to think about it carefully. >> Agreed. If the L2 cache is PIPT, then we should not do tie L1& L2 >> together and I'd like to change the code to remove the L2 cache >> operations from most places where we have them now. > > My point is the L2 caches better be PIPT. If the L2 cache are virtual indexed and we do not flush them on context change, then we could have multiple copies in the L2 cache when we share a page and the width of the level 2 cache is larger than a page. > > It only make sense from the hardware design side to make the L2 cache PIPT. I have no problem with VIVT L2 caches. You deal with L2 anywhere you deal with L1. In other words, you deal with them in cpu_idcache_* and cpu_dcache_*. That's probably also why cpu_l2cache_* is a sub-optimimal name. It's not so much a distinction between L1 & L2, but rather a distinction between VIVT & PIPT that is significant here. >> What I'm thinking about is the following: introduce pmap_switch(), >> as we have it on ia64. This function is called from cpu_switch to >> replace the existing active pmap with a new one. In pmap_switch() >> we flush the VIVT caches *IFF* the new pmap is different from the >> old (=currently active) pmap. Consequently, we're not going to >> flush the VIVT caches when we switch between kernel threads, nor >> do we flush the caches when we switch between threads in the >> same process. In all other cases we'll flush the VIVT caches. >> >> pmap_switch() is also called when a pmap interface function gets >> a pmap to work on. The interface function switches the pmap, (if >> applicable) which may or may not force a VIVT cache operation. >> The pmap interface function does it's work, after which it switches >> back to the pmap that was active on entry to the function. This >> then could also trigger VIVT cache operations. >> >> In any case: I'm thinking that this removes most of the explicit >> calls to the cache functions while still guaranteing coherency. >> >> I need to look into the aliasing case to see how that is handled. >> I have some ideas for that too... >> >> Thoughts? >> > There are places we can remove redundant cache operations; pmap_qenter() comes to mind. > > A lot of the cache operations outside of a context switch occur because we share a page within the same memory map (I think that is what you mean by the aliasing case), we turn access or writing off, and for dma. For VIVT caches, I can't see these operations going away. The page copying and zeroing are other examples and it seems like they need cache operations. As I said, I need to look at the current implementation, but in general my thinking is that you allow only 1 of the aliased VAs to be "active" or mapped. All other VAs that map to the same PA should cause a page fault. Handling the page fault should then: 1. flush the VIVT caches for the currently mapped VA. 2. Remove the currently mapped VA. 3. Add the new VA->PA mapping to satisfy the page fault. This assumes that we're not concurrently accessing the data through multiple aliased VAs. This, with pmap_switch() seems to be a lot more transparent, easier to comprehend and hopefully actually solves all outstanding problems we still have and it's hopefully more optimimal than what we have now. I have no proof that these ideas actually work or actually work more efficiently. That's why I'm discussing it here :-) ... -- Marcel Moolenaar xcllnt@mac.com From owner-freebsd-arm@FreeBSD.ORG Fri Feb 11 23:32:05 2011 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 70F231065670 for ; Fri, 11 Feb 2011 23:32:05 +0000 (UTC) (envelope-from torfinn.ingolfsen@broadpark.no) Received: from thalia-smout.broadpark.no (thalia-smout.broadpark.no [80.202.8.21]) by mx1.freebsd.org (Postfix) with ESMTP id 276908FC16 for ; Fri, 11 Feb 2011 23:32:04 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from terra-smin.broadpark.no ([80.202.8.13]) by thalia-smout.broadpark.no (Sun Java(tm) System Messaging Server 7u3-15.01 64bit (built Feb 12 2010)) with ESMTP id <0LGH0076481F1G80@thalia-smout.broadpark.no> for freebsd-arm@FreeBSD.org; Sat, 12 Feb 2011 00:32:03 +0100 (CET) Received: from kg-v2.kg4.no ([84.48.120.77]) by terra-smin.broadpark.no (Sun Java(tm) System Messaging Server 7u3-15.01 64bit (built Feb 12 2010)) with SMTP id <0LGH001QR81FGUB0@terra-smin.broadpark.no> for freebsd-arm@FreeBSD.org; Sat, 12 Feb 2011 00:32:03 +0100 (CET) Date: Sat, 12 Feb 2011 00:32:03 +0100 From: Torfinn Ingolfsen To: freebsd-arm@FreeBSD.org Message-id: <20110212003203.c4ed07d8.torfinn.ingolfsen@broadpark.no> In-reply-to: <20110207213437.9839d476.torfinn.ingolfsen@broadpark.no> References: <20110206181659.869861bf.torfinn.ingolfsen@broadpark.no> <201102062331.01760.hselasky@c2i.net> <20110207163835.41be5884.torfinn.ingolfsen@broadpark.no> <201102071656.11633.milu@dat.pl> <20110207204429.ae2fa012.torfinn.ingolfsen@broadpark.no> <20110207213437.9839d476.torfinn.ingolfsen@broadpark.no> X-Mailer: Sylpheed 3.0.3 (GTK+ 2.22.1; amd64-portbld-freebsd8.1) X-Face: "t9w2,-X@O^I`jVW\sonI3.,36KBLZE*AL[y9lL[PyFD*r_S:dIL9c[8Y>V42R0"!"yb_zN,f#%.[PYYNq; m"_0v; ~rUM2Yy!zmkh)3&U|u!=T(zyv,MHJv"nDH>OJ`t(@mil461d_B'Uo|'nMwlKe0Mv=kvV?Nh@>Hb<3s_z2jYgZhPb@?Wi^x1a~Hplz1.zH Cc: Subject: Re: FreeBSD on a DockStar - doesn't mount root 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: Fri, 11 Feb 2011 23:32:05 -0000 On Mon, 07 Feb 2011 21:34:37 +0100 Torfinn Ingolfsen wrote: > Another update: > > On Mon, 07 Feb 2011 20:44:29 +0100 > Torfinn Ingolfsen wrote: > > > FWIW, I have now tried with kern.cam.boot_delay=10000 > > in /boot/loader.conf (I also tried the value 20000), but it doesn't > > boot still. > > I have now tried with kern.cam.scsi_delay=10000 (also tried the value > 20000) instead of kern.cam.boot_delay in /boot/loader.conf > > Doesn't make the Dockstar boot, and doesn't make it hang. OTOH, how does the kernel read /boot/loader.conf and the settings in there if it can't mount the disk? -- Torfinn