From owner-freebsd-mips@FreeBSD.ORG Sun Jan 24 00:03:04 2010 Return-Path: Delivered-To: freebsd-mips@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4DFA7106566B for ; Sun, 24 Jan 2010 00:03:04 +0000 (UTC) (envelope-from smeagle@bsdler.de) Received: from hell.bsdler.de (hell-fe0.v6.bsdler.de [IPv6:2001:780:0:19::1]) by mx1.freebsd.org (Postfix) with ESMTP id D7F458FC1C for ; Sun, 24 Jan 2010 00:03:03 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by hell.bsdler.de (Postfix) with ESMTP id C7921B874 for ; Sun, 24 Jan 2010 01:03:01 +0100 (CET) X-Virus-Scanned: amavisd-new at bsdler.de Received: from hell.bsdler.de ([127.0.0.1]) by localhost (hell.bsdler.de [127.0.0.1]) (amavisd-new, port 10024) with LMTP id mZ4xw6c7PnEq for ; Sun, 24 Jan 2010 01:02:57 +0100 (CET) Received: from kiste.lan.terror.local (p5DD1DB78.dip.t-dialin.net [93.209.219.120]) by hell.bsdler.de (Postfix) with ESMTPSA id C39EAB873 for ; Sun, 24 Jan 2010 01:02:55 +0100 (CET) Received: from [172.17.21.80] (brain.lan.terror.local [172.17.21.80]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by kiste.lan.terror.local (Postfix) with ESMTPS id 07E404AE07 for ; Sun, 24 Jan 2010 01:31:31 +0100 (CET) From: Florian Kruegl To: freebsd-mips@freebsd.org Content-Type: text/plain; charset="us-ascii" Date: Sun, 24 Jan 2010 01:00:20 +0100 Message-ID: <1264291220.2647.2.camel@brain.lan.terror.local> Mime-Version: 1.0 X-Mailer: Evolution 2.28.2 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Subject: AR71XX RTC X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: smeagle@bsdler.de List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jan 2010 00:03:04 -0000 Hi, anyone working on pfc2123 driver for RouterStation Pro? Seems quite well documented, one issue might be CS hack, but the rest should be straight. Flo From owner-freebsd-mips@FreeBSD.ORG Sun Jan 24 00:09:40 2010 Return-Path: Delivered-To: freebsd-mips@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B4FB61065708 for ; Sun, 24 Jan 2010 00:09:40 +0000 (UTC) (envelope-from mmoll@darkthrone.kvedulv.de) Received: from darkthrone.kvedulv.de (darkthrone.kvedulv.de [IPv6:2001:1578:400:101::2]) by mx1.freebsd.org (Postfix) with ESMTP id 6465F8FC14 for ; Sun, 24 Jan 2010 00:09:40 +0000 (UTC) Received: by darkthrone.kvedulv.de (Postfix, from userid 666) id 21B981CC2B; Sun, 24 Jan 2010 01:09:39 +0100 (CET) Date: Sun, 24 Jan 2010 01:09:39 +0100 From: Michael Moll To: "M. Warner Losh" Message-ID: <20100124000938.GI23141@darkthrone.kvedulv.de> References: <20100123155657.GG23141@darkthrone.kvedulv.de> <20100123.113710.715074405929305890.imp@bsdimp.com> <20100123204257.GH23141@darkthrone.kvedulv.de> <20100123.144216.1084339115216047983.imp@bsdimp.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100123.144216.1084339115216047983.imp@bsdimp.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-mips@FreeBSD.org Subject: Re: NIC on RouterBoard 411 X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jan 2010 00:09:40 -0000 Hi Warner, On Sat, Jan 23, 2010 at 02:42:16PM -0700, M. Warner Losh wrote: > btw, do you know if there's a way to determine at run-time if we're > booting on this board? Not really, the OpenWRT people seem to get this information from the PROM or the bootloader somehow... But I'm not a programmer, so I can't tell really much from their sources. Kind Regards -- Michael Moll From owner-freebsd-mips@FreeBSD.ORG Sun Jan 24 00:21:36 2010 Return-Path: Delivered-To: freebsd-mips@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D27A11065693 for ; Sun, 24 Jan 2010 00:21:36 +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 7E81C8FC21 for ; Sun, 24 Jan 2010 00:21:36 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.3/8.14.1) with ESMTP id o0O0FhGn023981; Sat, 23 Jan 2010 17:15:43 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Sat, 23 Jan 2010 17:16:41 -0700 (MST) Message-Id: <20100123.171641.746477000994751399.imp@bsdimp.com> To: smeagle@bsdler.de From: "M. Warner Losh" In-Reply-To: <1264291220.2647.2.camel@brain.lan.terror.local> References: <1264291220.2647.2.camel@brain.lan.terror.local> X-Mailer: Mew version 6.3 on Emacs 22.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-mips@freebsd.org Subject: Re: AR71XX RTC X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jan 2010 00:21:36 -0000 In message: <1264291220.2647.2.camel@brain.lan.terror.local> Florian Kruegl writes: : Hi, : : anyone working on pfc2123 driver for RouterStation Pro? : Seems quite well documented, one issue might be CS hack, but the rest : should be straight. gonzo@freebsd.org has a working driver and should be committing it as soon as he figures out the best way to cope with the CS hack... Warner From owner-freebsd-mips@FreeBSD.ORG Sun Jan 24 00:21:56 2010 Return-Path: Delivered-To: freebsd-mips@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 95D1610656A3 for ; Sun, 24 Jan 2010 00:21:56 +0000 (UTC) (envelope-from gonzo@bluezbox.com) Received: from expo.ukrweb.net (mail.univua.net [91.202.128.78]) by mx1.freebsd.org (Postfix) with ESMTP id 474F88FC1C for ; Sun, 24 Jan 2010 00:21:56 +0000 (UTC) Received: from [174.6.209.117] (helo=[192.168.1.141]) by expo.ukrweb.net with esmtpa (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NYqEi-0008gd-4x; Sun, 24 Jan 2010 02:21:55 +0200 Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Oleksandr Tymoshenko In-Reply-To: <1264291220.2647.2.camel@brain.lan.terror.local> Date: Sat, 23 Jan 2010 16:21:50 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <77401129-0991-44BE-88A5-F4AA0E347703@bluezbox.com> References: <1264291220.2647.2.camel@brain.lan.terror.local> To: smeagle@bsdler.de X-Mailer: Apple Mail (2.1077) X-SA-Exim-Connect-IP: 174.6.209.117 X-SA-Exim-Mail-From: gonzo@bluezbox.com X-SA-Exim-Scanned: No (on expo.ukrweb.net); SAEximRunCond expanded to false X-Spam-Level: / X-Spam-Report: -1.8 ALL_TRUSTED Passed through trusted hosts only via SMTP 0.0 BAYES_50 BODY: Bayesian spam probability is 40 to 60% [score: 0.4998] 1.1 AWL AWL: From: address is in the auto white-list Cc: freebsd-mips@freebsd.org Subject: Re: AR71XX RTC X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jan 2010 00:21:56 -0000 On 2010-01-23, at 4:00 PM, Florian Kruegl wrote: > Hi, >=20 > anyone working on pfc2123 driver for RouterStation Pro?=20 > Seems quite well documented, one issue might be CS hack, but the rest > should be straight. Driver was commited yesterday: http://svn.freebsd.org/viewvc/base?view=3Drevision&revision=3D202839 And yes, CS hack is the problem. I'm trying to figure out how to fit it = into FreeBSD SPI framework.=20= From owner-freebsd-mips@FreeBSD.ORG Sun Jan 24 00:36:48 2010 Return-Path: Delivered-To: freebsd-mips@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 55B35106566B for ; Sun, 24 Jan 2010 00:36:48 +0000 (UTC) (envelope-from gonzo@bluezbox.com) Received: from expo.ukrweb.net (mail.univua.net [91.202.128.78]) by mx1.freebsd.org (Postfix) with ESMTP id AF5258FC13 for ; Sun, 24 Jan 2010 00:36:47 +0000 (UTC) Received: from [174.6.209.117] (helo=[192.168.1.141]) by expo.ukrweb.net with esmtpa (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NYqT3-0008nu-On; Sun, 24 Jan 2010 02:36:44 +0200 Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Oleksandr Tymoshenko In-Reply-To: <20100123.144216.1084339115216047983.imp@bsdimp.com> Date: Sat, 23 Jan 2010 16:36:39 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20100123155657.GG23141@darkthrone.kvedulv.de> <20100123.113710.715074405929305890.imp@bsdimp.com> <20100123204257.GH23141@darkthrone.kvedulv.de> <20100123.144216.1084339115216047983.imp@bsdimp.com> To: M. Warner Losh X-Mailer: Apple Mail (2.1077) X-SA-Exim-Connect-IP: 174.6.209.117 X-SA-Exim-Mail-From: gonzo@bluezbox.com X-SA-Exim-Scanned: No (on expo.ukrweb.net); SAEximRunCond expanded to false X-Spam-Level: - X-Spam-Report: -1.8 ALL_TRUSTED Passed through trusted hosts only via SMTP -0.2 BAYES_40 BODY: Bayesian spam probability is 20 to 40% [score: 0.3579] 0.9 AWL AWL: From: address is in the auto white-list Cc: freebsd-mips@FreeBSD.org Subject: Re: NIC on RouterBoard 411 X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jan 2010 00:36:48 -0000 On 2010-01-23, at 1:42 PM, M. Warner Losh wrote: > In message: <20100123204257.GH23141@darkthrone.kvedulv.de> > Michael Moll writes: > : Hi Warner, > :=20 > : On Sat, Jan 23, 2010 at 11:37:10AM -0700, M. Warner Losh wrote: > : > This is the mask of PHY addresses. If you have the documentation = for > : > the PHY addresses on your board, create a bitmask from that. If = you > : > lack documentation, trial an error likely can have good results = since > : > there's only 32 possible addresses the PHYs could be wired to. > :=20 > : Thanks, it now boots multiuser with hint.arge.0.phymask=3D0x0e >=20 > Cool. Maybe I'll create a hints file for it. >=20 > btw, do you know if there's a way to determine at run-time if we're > booting on this board? Last time I checked hardware configuration was set at build-time. There = are files=20 named mach-XXXX.c. Each file acts effectively like FreeBSD's XXXX.hints. = Only that C file is a little bit more flexible then hints description language :) =20= From owner-freebsd-mips@FreeBSD.ORG Sun Jan 24 01:44:50 2010 Return-Path: Delivered-To: freebsd-mips@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 390991065692 for ; Sun, 24 Jan 2010 01:44:50 +0000 (UTC) (envelope-from smeagle@bsdler.de) Received: from hell.bsdler.de (hell-fe0.v6.bsdler.de [IPv6:2001:780:0:19::1]) by mx1.freebsd.org (Postfix) with ESMTP id BF9708FC08 for ; Sun, 24 Jan 2010 01:44:49 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by hell.bsdler.de (Postfix) with ESMTP id 8E7E8B874; Sun, 24 Jan 2010 02:44:47 +0100 (CET) X-Virus-Scanned: amavisd-new at bsdler.de Received: from hell.bsdler.de ([127.0.0.1]) by localhost (hell.bsdler.de [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 1VOlChJHGCjo; Sun, 24 Jan 2010 02:44:42 +0100 (CET) Received: from kiste.lan.terror.local (p4FF0BF81.dip.t-dialin.net [79.240.191.129]) by hell.bsdler.de (Postfix) with ESMTPSA id 866EFB873; Sun, 24 Jan 2010 02:44:35 +0100 (CET) Received: from [172.17.21.80] (brain.lan.terror.local [172.17.21.80]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by kiste.lan.terror.local (Postfix) with ESMTPS id CB6904AE07; Sun, 24 Jan 2010 03:13:05 +0100 (CET) From: Florian Kruegl To: Oleksandr Tymoshenko In-Reply-To: References: <1264291220.2647.2.camel@brain.lan.terror.local> <77401129-0991-44BE-88A5-F4AA0E347703@bluezbox.com> <1264293898.2647.15.camel@brain.lan.terror.local> Content-Type: text/plain; charset="us-ascii" Date: Sun, 24 Jan 2010 02:41:51 +0100 Message-ID: <1264297311.2647.51.camel@brain.lan.terror.local> Mime-Version: 1.0 X-Mailer: Evolution 2.28.2 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-mips@freebsd.org Subject: Re: AR71XX RTC X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: smeagle@bsdler.de List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jan 2010 01:44:50 -0000 On Sat, 2010-01-23 at 16:53 -0800, Oleksandr Tymoshenko wrote: > On 2010-01-23, at 4:44 PM, Florian Kruegl wrote: > > > Hi, > > > > On Sat, 2010-01-23 at 16:21 -0800, Oleksandr Tymoshenko wrote: > >> On 2010-01-23, at 4:00 PM, Florian Kruegl wrote: > >> > >>> Hi, > >>> > >>> anyone working on pfc2123 driver for RouterStation Pro? > >>> Seems quite well documented, one issue might be CS hack, but the rest > >>> should be straight. > >> Driver was commited yesterday: > >> http://svn.freebsd.org/viewvc/base?view=revision&revision=202839 > >> > >> And yes, CS hack is the problem. I'm trying to figure out how to fit it into FreeBSD > >> SPI framework. > > > > sounds good, will do an update as soon as i removed me work from code. > > My CS "solution" was more than crude, but the frames simply didn't > > fit... so I am looking forward for a different one :) > > Yeah, my CS solution was dirty hack too. If for "didn't fit" you mean missing last > byte of frame then this problem was solved to. Bug was in AR71XX SPI code: falling > edge was not provided for last byte in transfer in time and RTC chip acts of falling edge. > Fix was committed before driver. > > > code looks similar, can't tell much about result as kernel hangs for a while before getting this: <<<<<<<<<<<<<<<<<<<<<<<<<<< schnipp >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Trap cause = 2 (TLB miss (load or instr. fetch) - kernel mode) [thread pid 4 tid 100009 ] Stopped at _thread_lock_flags+0x150: lw v0,60(a3) db> bt Tracing pid 4 tid 100009 td 0xc0c47270 db_trace_thread+30 (?,?,?,?) ra 800a6c10 sz 24 800a6af4+11c (0,?,ffffffff,?) ra 800a6604 sz 32 800a6270+394 (?,?,?,?) ra 800a6794 sz 168 db_command_loop+78 (?,?,?,?) ra 800a8e68 sz 24 800a8d60+108 (?,?,?,?) ra 80215ff8 sz 424 kdb_trap+f8 (?,?,?,?) ra 80474350 sz 32 trap+134c (?,?,?,?) ra 8046b7fc sz 176 MipsKernGenException+100 (b,173,804d5de8,deadc0d8) ra 801c593c sz 200 _thread_lock_flags+130 (?,?,?,?) ra 80221f18 sz 56 sleepq_broadcast+ac (?,?,?,?) ra 801e5f20 sz 40 wakeup+2c (?,?,?,?) ra 8016de18 sz 32 g_io_deliver+198 (?,?,?,?) ra 8016bbd4 sz 80 8016b590+644 (?,?,?,?) ra 8016e184 sz 104 g_io_schedule_down+2ec (?,?,?,?) ra 8016eb94 sz 64 8016eb18+7c (?,?,?,?) ra 801a331c sz 24 fork_exit+a0 (?,?,?,?) ra 80478f10 sz 48 fork_trampoline+10 (?,?,?,?) ra 0 sz 0 pid 4 <<<<<<<<<<<<<<<<<<<<<<<<<<< schnapp >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> will use AR71XX as config file tomorrow, mine has many additional devs configured for booting from usb devices. and speaking about delay, I managed to boot using SD-Cards and USB Sticks as rootfs by adding a (configurable) delay to root_mount_prepare(). I am quite good in delaying things. usbus1 is finished, but scsi device is not yet ready. I wonder if SCSI_DELAY should do the trick, but I didn't give it a try. as I believe it's only used for physical SCSI bus. Flo From owner-freebsd-mips@FreeBSD.ORG Sun Jan 24 01:56:59 2010 Return-Path: Delivered-To: freebsd-mips@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 393721065694 for ; Sun, 24 Jan 2010 01:56:59 +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 EC1098FC13 for ; Sun, 24 Jan 2010 01:56:58 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.3/8.14.1) with ESMTP id o0O1moY0024747; Sat, 23 Jan 2010 18:48:50 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Sat, 23 Jan 2010 18:49:48 -0700 (MST) Message-Id: <20100123.184948.807935107107560660.imp@bsdimp.com> To: gonzo@bluezbox.com From: "M. Warner Losh" In-Reply-To: References: <20100123204257.GH23141@darkthrone.kvedulv.de> <20100123.144216.1084339115216047983.imp@bsdimp.com> X-Mailer: Mew version 6.3 on Emacs 22.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-mips@freebsd.org Subject: Re: NIC on RouterBoard 411 X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jan 2010 01:56:59 -0000 In message: Oleksandr Tymoshenko writes: : : On 2010-01-23, at 1:42 PM, M. Warner Losh wrote: : : > In message: <20100123204257.GH23141@darkthrone.kvedulv.de> : > Michael Moll writes: : > : Hi Warner, : > : : > : On Sat, Jan 23, 2010 at 11:37:10AM -0700, M. Warner Losh wrote: : > : > This is the mask of PHY addresses. If you have the documentation for : > : > the PHY addresses on your board, create a bitmask from that. If you : > : > lack documentation, trial an error likely can have good results since : > : > there's only 32 possible addresses the PHYs could be wired to. : > : : > : Thanks, it now boots multiuser with hint.arge.0.phymask=0x0e : > : > Cool. Maybe I'll create a hints file for it. : > : > btw, do you know if there's a way to determine at run-time if we're : > booting on this board? : : Last time I checked hardware configuration was set at : build-time. There are files named mach-XXXX.c. Each file acts : effectively like FreeBSD's XXXX.hints. Only that C file is a little : bit more flexible then hints description language :) I thought it grovelled through the information passed in from the boot loader to figure it out... Warner From owner-freebsd-mips@FreeBSD.ORG Sun Jan 24 16:55:02 2010 Return-Path: Delivered-To: freebsd-mips@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C861C1065692 for ; Sun, 24 Jan 2010 16:55:02 +0000 (UTC) (envelope-from smeagle@bsdler.de) Received: from hell.bsdler.de (hell-fe0.v6.bsdler.de [IPv6:2001:780:0:19::1]) by mx1.freebsd.org (Postfix) with ESMTP id EEDAA8FC18 for ; Sun, 24 Jan 2010 16:55:01 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by hell.bsdler.de (Postfix) with ESMTP id D4FF1B874; Sun, 24 Jan 2010 17:54:59 +0100 (CET) X-Virus-Scanned: amavisd-new at bsdler.de Received: from hell.bsdler.de ([127.0.0.1]) by localhost (hell.bsdler.de [127.0.0.1]) (amavisd-new, port 10024) with LMTP id QWaOE0gfqOu1; Sun, 24 Jan 2010 17:54:59 +0100 (CET) Received: from kiste.lan.terror.local (p4FF0ADED.dip.t-dialin.net [79.240.173.237]) by hell.bsdler.de (Postfix) with ESMTPSA id 24955B83D; Sun, 24 Jan 2010 17:54:58 +0100 (CET) Received: from [172.17.21.80] (brain.lan.terror.local [172.17.21.80]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by kiste.lan.terror.local (Postfix) with ESMTPS id 8451F4AE07; Sun, 24 Jan 2010 18:24:16 +0100 (CET) From: Florian Kruegl To: Oleksandr Tymoshenko In-Reply-To: <1264297311.2647.51.camel@brain.lan.terror.local> References: <1264291220.2647.2.camel@brain.lan.terror.local> <77401129-0991-44BE-88A5-F4AA0E347703@bluezbox.com> <1264293898.2647.15.camel@brain.lan.terror.local> <1264297311.2647.51.camel@brain.lan.terror.local> Content-Type: text/plain; charset="us-ascii" Date: Sun, 24 Jan 2010 17:52:31 +0100 Message-ID: <1264351951.2647.93.camel@brain.lan.terror.local> Mime-Version: 1.0 X-Mailer: Evolution 2.28.2 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-mips@freebsd.org Subject: Re: AR71XX RTC X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: smeagle@bsdler.de List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jan 2010 16:55:02 -0000 Hi, On Sun, 2010-01-24 at 02:41 +0100, Florian Kruegl wrote: > On Sat, 2010-01-23 at 16:53 -0800, Oleksandr Tymoshenko wrote: > > On 2010-01-23, at 4:44 PM, Florian Kruegl wrote: > > > > > Hi, > > > > > > On Sat, 2010-01-23 at 16:21 -0800, Oleksandr Tymoshenko wrote: > > >> On 2010-01-23, at 4:00 PM, Florian Kruegl wrote: > > >> > > >>> Hi, > > >>> > > >>> anyone working on pfc2123 driver for RouterStation Pro? > > >>> Seems quite well documented, one issue might be CS hack, but the rest > > >>> should be straight. > > >> Driver was commited yesterday: > > >> http://svn.freebsd.org/viewvc/base?view=revision&revision=202839 > > >> > > >> And yes, CS hack is the problem. I'm trying to figure out how to fit it into FreeBSD > > >> SPI framework. > > > > > > sounds good, will do an update as soon as i removed me work from code. > > > My CS "solution" was more than crude, but the frames simply didn't > > > fit... so I am looking forward for a different one :) > > > > Yeah, my CS solution was dirty hack too. If for "didn't fit" you mean missing last > > byte of frame then this problem was solved to. Bug was in AR71XX SPI code: falling > > edge was not provided for last byte in transfer in time and RTC chip acts of falling edge. > > Fix was committed before driver. > > > > > > > > code looks similar, can't tell much about result as kernel hangs for a > while before getting this: > <<<<<<<<<<<<<<<<<<<<<<<<<<< schnipp >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > Trap cause = 2 (TLB miss (load or instr. fetch) - kernel mode) > [thread pid 4 tid 100009 ] > Stopped at _thread_lock_flags+0x150: lw v0,60(a3) > db> bt > Tracing pid 4 tid 100009 td 0xc0c47270 > db_trace_thread+30 (?,?,?,?) ra 800a6c10 sz 24 > 800a6af4+11c (0,?,ffffffff,?) ra 800a6604 sz 32 > 800a6270+394 (?,?,?,?) ra 800a6794 sz 168 > db_command_loop+78 (?,?,?,?) ra 800a8e68 sz 24 > 800a8d60+108 (?,?,?,?) ra 80215ff8 sz 424 > kdb_trap+f8 (?,?,?,?) ra 80474350 sz 32 > trap+134c (?,?,?,?) ra 8046b7fc sz 176 > MipsKernGenException+100 (b,173,804d5de8,deadc0d8) ra 801c593c sz 200 > _thread_lock_flags+130 (?,?,?,?) ra 80221f18 sz 56 > sleepq_broadcast+ac (?,?,?,?) ra 801e5f20 sz 40 > wakeup+2c (?,?,?,?) ra 8016de18 sz 32 > g_io_deliver+198 (?,?,?,?) ra 8016bbd4 sz 80 > 8016b590+644 (?,?,?,?) ra 8016e184 sz 104 > g_io_schedule_down+2ec (?,?,?,?) ra 8016eb94 sz 64 > 8016eb18+7c (?,?,?,?) ra 801a331c sz 24 > fork_exit+a0 (?,?,?,?) ra 80478f10 sz 48 > fork_trampoline+10 (?,?,?,?) ra 0 sz 0 > pid 4 > <<<<<<<<<<<<<<<<<<<<<<<<<<< schnapp >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > > will use AR71XX as config file tomorrow, mine has many additional devs > configured for booting from usb devices. > [...] seems to make no difference. removed all mini pci devs and most code changes. kernel hangs during bootup for a while. then gets a trap. Source Info: -------------------------- schnipp -------------------------- brain:head> svn info Path: . URL: svn://svn.freebsd.org/base/head Repository Root: svn://svn.freebsd.org/base Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f Revision: 202904 Node Kind: directory Schedule: normal Last Changed Author: marcel Last Changed Rev: 202904 Last Changed Date: 2010-01-24 00:16:50 +0100 (Sun, 24 Jan 2010) -------------------------- schnapp -------------------------- -------------------------- schnipp -------------------------- brain:head> svn stat ? GRTAGS ? GSYMS ? GTAGS ? GPATH M sys/kern/vfs_mount.c M sys/mips/conf/AR71XX ? sys/dev/pfc2123 -------------------------- schnapp -------------------------- - vfs_mount should be far away. - sys/dev/pfc2123 is no longer used. - sys/mips/conf/AR71XX altered to include pfc2123_rtc -------------------------- schnipp -------------------------- FreeBSD 9.0-CURRENT #1: Sun Jan 24 15:58:37 UTC 2010 root@pinky.lan.terror.local:/home/smeagle/obj/mips/mips/home/smeagle/src/freebsd/head/sys/AR71XX mips real memory = 134217728 (131072K bytes) avail memory = 125689856 (119MB) nexus0: clock0: on nexus0 clock0: [FILTER] apb0 at irq 4 on nexus0 apb0: [FILTER] uart0: <16550 or compatible> on apb0 uart0: [FILTER] uart0: console (115200,n,8,1) pcib0 at irq 0 on nexus0 pcib0: [FILTER] pci0: on pcib0 pci0: at device 0.0 (no driver attached) pci0: at device 17.0 (no driver attached) arge0: at mem 0x19000000-0x19000fff irq 2 on nexus0 miibus0: on arge0 ukphy0: PHY 4 on miibus0 ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT-FDX, auto arge0: Ethernet address: 00:00:00:00:46:61 arge0: [FILTER+ITHREAD] arge1: at mem 0x1a000000-0x1a000fff irq 3 on nexus0 arge1: Ethernet address: 00:00:00:00:46:62 arge1: [FILTER+ITHREAD] spi0: at mem 0x1f000000-0x1f00000f on nexus0 spibus0: on spi0 mx25l0: at cs 0 on spibus0 mx25l0: mx25ll128, sector 65536 bytes, 256 sectors ar71xx_wdog0: on nexus0 Timecounter "MIPS32" frequency 360000000 Hz quality 800 Timecounters tick every 1.000 msec bootpc_init: wired to interface 'arge0' Sending DHCP Discover packet from interface arge0 (00:00:00:00:46:61) arge0: link state changed to DOWN Trap cause = 2 (TLB miss (load or instr. fetch) - kernel mode) [thread pid 4 tid 100008 ] Stopped at _thread_lock_flags+0x150: lw v0,60(a3) db> bt Tracing pid 4 tid 100008 td 0xc0c414e0 db_trace_thread+30 (?,?,?,?) ra 80055900 sz 24 800557e4+11c (0,?,ffffffff,?) ra 800552f4 sz 32 80054f60+394 (?,?,?,?) ra 80055484 sz 168 db_command_loop+78 (?,?,?,?) ra 80057b58 sz 24 80057a50+108 (?,?,?,?) ra 8017b7d8 sz 424 kdb_trap+f8 (?,?,?,?) ra 8035ab40 sz 32 trap+134c (?,?,?,?) ra 80351fec sz 176 MipsKernGenException+100 (b,173,8039ce74,deadc0d8) ra 8012c92c sz 200 _thread_lock_flags+130 (?,?,?,?) ra 801876f8 sz 56 sleepq_broadcast+ac (?,?,?,?) ra 8014b700 sz 40 wakeup+2c (?,?,?,?) ra 800d6ba8 sz 32 g_io_deliver+198 (?,?,?,?) ra 800d4964 sz 80 800d4320+644 (?,?,?,?) ra 800d6f14 sz 104 g_io_schedule_down+2ec (?,?,?,?) ra 800d7924 sz 64 800d78a8+7c (?,?,?,?) ra 8010c0ac sz 24 fork_exit+a0 (?,?,?,?) ra 8035f700 sz 48 fork_trampoline+10 (?,?,?,?) ra 0 sz 0 pid 4 -------------------------- schnapp -------------------------- Flo From owner-freebsd-mips@FreeBSD.ORG Mon Jan 25 00:13:20 2010 Return-Path: Delivered-To: freebsd-mips@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A3A5B106566C for ; Mon, 25 Jan 2010 00:13:20 +0000 (UTC) (envelope-from smeagle@bsdler.de) Received: from hell.bsdler.de (hell-fe0.v6.bsdler.de [IPv6:2001:780:0:19::1]) by mx1.freebsd.org (Postfix) with ESMTP id 2F7828FC1C for ; Mon, 25 Jan 2010 00:13:20 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by hell.bsdler.de (Postfix) with ESMTP id 03C37B874 for ; Mon, 25 Jan 2010 01:13:18 +0100 (CET) X-Virus-Scanned: amavisd-new at bsdler.de Received: from hell.bsdler.de ([127.0.0.1]) by localhost (hell.bsdler.de [127.0.0.1]) (amavisd-new, port 10024) with LMTP id hoh3Vzkt85hp for ; Mon, 25 Jan 2010 01:13:13 +0100 (CET) Received: from kiste.lan.terror.local (p4FF0B0BD.dip.t-dialin.net [79.240.176.189]) by hell.bsdler.de (Postfix) with ESMTPSA id 918DEB83D for ; Mon, 25 Jan 2010 01:13:11 +0100 (CET) Received: from [172.17.21.80] (brain.lan.terror.local [172.17.21.80]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by kiste.lan.terror.local (Postfix) with ESMTPS id BFB534AE07 for ; Mon, 25 Jan 2010 01:42:24 +0100 (CET) From: Florian Kruegl To: freebsd-mips@freebsd.org In-Reply-To: <1264351951.2647.93.camel@brain.lan.terror.local> References: <1264291220.2647.2.camel@brain.lan.terror.local> <77401129-0991-44BE-88A5-F4AA0E347703@bluezbox.com> <1264293898.2647.15.camel@brain.lan.terror.local> <1264297311.2647.51.camel@brain.lan.terror.local> <1264351951.2647.93.camel@brain.lan.terror.local> Content-Type: text/plain; charset="us-ascii" Date: Mon, 25 Jan 2010 01:10:24 +0100 Message-ID: <1264378224.2647.97.camel@brain.lan.terror.local> Mime-Version: 1.0 X-Mailer: Evolution 2.28.2 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Subject: Re: AR71XX RTC X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: smeagle@bsdler.de List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jan 2010 00:13:20 -0000 Hi, On Sun, 2010-01-24 at 17:52 +0100, Florian Kruegl wrote: > Hi, > > On Sun, 2010-01-24 at 02:41 +0100, Florian Kruegl wrote: > > On Sat, 2010-01-23 at 16:53 -0800, Oleksandr Tymoshenko wrote: > > > On 2010-01-23, at 4:44 PM, Florian Kruegl wrote: > > > > > > > Hi, > > > > > > > > On Sat, 2010-01-23 at 16:21 -0800, Oleksandr Tymoshenko wrote: > > > >> On 2010-01-23, at 4:00 PM, Florian Kruegl wrote: > > > >> > > > >>> Hi, > > > >>> > > > >>> anyone working on pfc2123 driver for RouterStation Pro? > > > >>> Seems quite well documented, one issue might be CS hack, but the rest > > > >>> should be straight. > > > >> Driver was commited yesterday: > > > >> http://svn.freebsd.org/viewvc/base?view=revision&revision=202839 > > > >> forget about previous post(s), traps were not related to pfc2123 driver, as removing driver from kernel config made no change ;) updated to revision 202839 and kernel trap is gone. Flo From owner-freebsd-mips@FreeBSD.ORG Mon Jan 25 09:31:00 2010 Return-Path: Delivered-To: freebsd-mips@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 894F21065676 for ; Mon, 25 Jan 2010 09:31:00 +0000 (UTC) (envelope-from neelnatu@yahoo.com) Received: from web34405.mail.mud.yahoo.com (web34405.mail.mud.yahoo.com [66.163.178.154]) by mx1.freebsd.org (Postfix) with SMTP id 523F18FC1C for ; Mon, 25 Jan 2010 09:30:59 +0000 (UTC) Received: (qmail 57750 invoked by uid 60001); 25 Jan 2010 09:30:59 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1264411859; bh=M27jNvTTLX6ZFutBeWV8p6uBxFOkK6ZuKjCRFk7CxSA=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=bZ9mNX4PmfNCUZGZdr+pILu6SBrXhazDNilEkEcZStbuKVX3DfFgjyxd1HaN0O/Lcltpzq3Q7KFsoERUpvDivI4DoqW874kzlG8UjoPBjwRQGrvKwxcU8ocPHO0wXyKPOUnNaCsDe0W2WTJi1NcQnGtjLabsxXV4/KndefV9BXI= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=qvtRD73VhyJord+vxEmdLzJrlBjKGfmAw/StzaGOaPXe/SXdBy1iNrCT0TpGvdZhGroGKY+Iej9cbLM8J+lamkRsmZgMy0dg/OvI0jmUSSR2GSgq1HsD62CXA8dUw6irjGuVBC+ktQWg4iDqnq13WCbVr90S/CvnsiiZjxEr9Ro=; Message-ID: <434364.57659.qm@web34405.mail.mud.yahoo.com> X-YMail-OSG: e_BpJ8AVM1muq4.Be5xd.jip3qEsNo6nYYJBe0m2KvxEbCGdTDxD9lLMePC0ZjoU5xysik8TC2KUAxj1XoJLSwtWEn3E0GvgNWAf0koYMx3pILaNQsvaIXTOCr36u.ZiG4Fy2ek75FgNzDW.o_HA8.o0t5PhbQUY_JHEY2YanWhBt57_7K0Q1wHin.UcPm0uWA8n09FfPpSODX7W7y1gSLSVf1emIeXSDfdFNC0ILhGlLvqAUkkTFS8etwOsXyBcbi6ovv3fxqgu2RtPK7Vje3KIk8lNhHRcWmxttbu9Q0hO5OpQ2BmlgGFZe.4rMSgA5SPngI2m9Z_uyhIn6Z8V40gYl8.upbiaR0cAqVYzSk2SP5ylk6kn68mS36lExBZ7OIAU9eyhHgSUs.gskUW0Um9UQ2WeB8SQGI23P7Bob1v3DTEN4YzIaeGR9Yzt Received: from [198.95.226.230] by web34405.mail.mud.yahoo.com via HTTP; Mon, 25 Jan 2010 01:30:59 PST X-Mailer: YahooMailClassic/9.1.10 YahooMailWebService/0.8.100.260964 Date: Mon, 25 Jan 2010 01:30:59 -0800 (PST) From: Neelkanth Natu To: Oleksandr Tymoshenko , smeagle@bsdler.de In-Reply-To: <1264351951.2647.93.camel@brain.lan.terror.local> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-mips@freebsd.org Subject: Re: AR71XX RTC X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jan 2010 09:31:00 -0000 Hi Flo,=0A=0ACan you try the following patch and see if it helps with the = =0Ahang-followed-by-trap problem?=0A=0AI am seeing a similar problem on the= Sibyte and this patch gets me=0Apast it.=0A=0Abest=0ANeel=0A=0AIndex: swtc= h.S=0A=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=0A--- swtch.S=09(= revision 202961)=0A+++ swtch.S=09(working copy)=0A@@ -323,7 +323,7 @@=0A = =09 * to be saved with the other registers do so here.=0A =09 */=0A =0A-=09= sw=09a3, TD_LOCK(a0)=09=09=09# Switchout td_lock =0A+=09sw=09a2, TD_LOCK(a3= )=09=09=09# Switchout td_lock =0A =0A mips_sw1:=0A #if defined(SMP) && defi= ned(SCHED_ULE)=0A=0A=0A--- On Sun, 1/24/10, Florian Kruegl wrote:=0A=0A> From: Florian Kruegl =0A> Subject: Re:= AR71XX RTC=0A> To: "Oleksandr Tymoshenko" =0A> Cc: fre= ebsd-mips@freebsd.org=0A> Date: Sunday, January 24, 2010, 8:52 AM=0A> Hi,= =0A> =0A> On Sun, 2010-01-24 at 02:41 +0100, Florian Kruegl wrote:=0A> > On= Sat, 2010-01-23 at 16:53 -0800, Oleksandr=0A> Tymoshenko wrote:=0A> > > On= 2010-01-23, at 4:44 PM, Florian Kruegl wrote:=0A> > > =0A> > > > Hi,=0A> >= > > =0A> > > > On Sat, 2010-01-23 at 16:21 -0800, Oleksandr=0A> Tymoshenko= wrote:=0A> > > >> On 2010-01-23, at 4:00 PM, Florian=0A> Kruegl wrote:=0A>= > > >> =0A> > > >>> Hi,=0A> > > >>> =0A> > > >>> anyone working on pfc2123= driver for=0A> RouterStation Pro? =0A> > > >>> Seems quite well documented= , one=0A> issue might be CS hack, but the rest=0A> > > >>> should be straig= ht.=0A> > > >>=A0 =A0 Driver was commited=0A> yesterday:=0A> > > >> http://= svn.freebsd.org/viewvc/base?view=3Drevision&revision=3D202839=0A> > > >> = =0A> > > >> And yes, CS hack is the problem. I'm=0A> trying to figure out h= ow to fit it into FreeBSD=0A> > > >> SPI framework. =0A> > > > =0A> > > > s= ounds good, will do an update as soon as i=0A> removed me work from code.= =0A> > > > My CS "solution" was more than crude, but=0A> the frames simply = didn't=0A> > > > fit... so I am looking forward for a=0A> different one :) = =0A> > > =0A> > >=A0 =A0=A0=A0Yeah, my CS solution was=0A> dirty hack too. = If for "didn't fit" you mean missing last =0A> > > byte of frame then this = problem was solved to.=0A> Bug was in AR71XX SPI code: falling =0A> > > edg= e was not provided for last byte in transfer=0A> in time and RTC chip acts = of falling edge. =0A> > > Fix was committed before driver.=0A> > > =0A> > >= =0A> > > =0A> > =0A> > code looks similar, can't tell much about result as= =0A> kernel hangs for a=0A> > while before getting this:=0A> >=0A> <<<<<<<<= <<<<<<<<<<<<<<<<<<<=0A> schnipp=0A> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>=0A> > T= rap cause =3D 2 (TLB miss (load or instr. fetch) -=0A> kernel mode)=0A> > [= thread pid 4 tid 100009 ]=0A> > Stopped at=A0 =A0 =A0=0A> _thread_lock_flag= s+0x150:=A0 =A0=0A> =A0=A0=A0lw=A0 =A0 =A0 v0,60(a3)=0A> > db> bt=0A> > Tra= cing pid 4 tid 100009 td 0xc0c47270=0A> > db_trace_thread+30 (?,?,?,?) ra 8= 00a6c10 sz 24=0A> > 800a6af4+11c (0,?,ffffffff,?) ra 800a6604 sz 32=0A> > 8= 00a6270+394 (?,?,?,?) ra 800a6794 sz 168=0A> > db_command_loop+78 (?,?,?,?)= ra 800a8e68 sz 24=0A> > 800a8d60+108 (?,?,?,?) ra 80215ff8 sz 424=0A> > kd= b_trap+f8 (?,?,?,?) ra 80474350 sz 32=0A> > trap+134c (?,?,?,?) ra 8046b7fc= sz 176=0A> > MipsKernGenException+100 (b,173,804d5de8,deadc0d8) ra=0A> 801= c593c sz 200=0A> > _thread_lock_flags+130 (?,?,?,?) ra 80221f18 sz 56=0A> >= sleepq_broadcast+ac (?,?,?,?) ra 801e5f20 sz 40=0A> > wakeup+2c (?,?,?,?) = ra 8016de18 sz 32=0A> > g_io_deliver+198 (?,?,?,?) ra 8016bbd4 sz 80=0A> > = 8016b590+644 (?,?,?,?) ra 8016e184 sz 104=0A> > g_io_schedule_down+2ec (?,?= ,?,?) ra 8016eb94 sz 64=0A> > 8016eb18+7c (?,?,?,?) ra 801a331c sz 24=0A> >= fork_exit+a0 (?,?,?,?) ra 80478f10 sz 48=0A> > fork_trampoline+10 (?,?,?,?= ) ra 0 sz 0=0A> > pid 4=0A> >=0A> <<<<<<<<<<<<<<<<<<<<<<<<<<<=0A> schnapp= =0A> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>=0A> > =0A> > will use AR71XX as config= file tomorrow, mine has many=0A> additional devs=0A> > configured for boot= ing from usb devices.=0A> > =0A> [...]=0A> =0A> seems to make no difference= . removed all mini pci=0A> devs=A0 and most code=0A> changes. kernel hangs = during bootup for a while. then gets=0A> a trap. =0A> =0A> Source Info:=0A>= =0A> -------------------------- schnipp=0A> --------------------------=0A>= brain:head> svn info=0A> Path: .=0A> URL: svn://svn.freebsd.org/base/head= =0A> Repository Root: svn://svn.freebsd.org/base=0A> Repository UUID: ccf9f= 872-aa2e-dd11-9fc8-001c23d0bc1f=0A> Revision: 202904=0A> Node Kind: directo= ry=0A> Schedule: normal=0A> Last Changed Author: marcel=0A> Last Changed Re= v: 202904=0A> Last Changed Date: 2010-01-24 00:16:50 +0100 (Sun, 24 Jan=0A>= 2010)=0A> -------------------------- schnapp=0A> -------------------------= -=0A> =0A> -------------------------- schnipp=0A> -------------------------= -=0A> brain:head> svn stat=0A> ?=A0 =A0 =A0=A0=A0GRTAGS=0A> ?=A0 =A0 =A0=A0= =A0GSYMS=0A> ?=A0 =A0 =A0=A0=A0GTAGS=0A> ?=A0 =A0 =A0=A0=A0GPATH=0A> M=A0 = =A0 =A0=A0=A0sys/kern/vfs_mount.c=0A> M=A0 =A0 =A0=A0=A0sys/mips/conf/AR71X= X=0A> ?=A0 =A0 =A0=A0=A0sys/dev/pfc2123=0A> -------------------------- schn= app=0A> --------------------------=0A> =0A> - vfs_mount should be far away.= =0A> - sys/dev/pfc2123 is no longer used.=0A> - sys/mips/conf/AR71XX alter= ed to include pfc2123_rtc=0A> =0A> =0A> -------------------------- schnipp= =0A> --------------------------=0A> FreeBSD 9.0-CURRENT #1: Sun Jan 24 15:5= 8:37 UTC 2010=0A> =0A> root@pinky.lan.terror.local:/home/smeagle/obj/mips/m= ips/home/smeagle/src/freebsd/head/sys/AR71XX=0A> mips=0A> real memory=A0 = =3D 134217728 (131072K bytes)=0A> avail memory =3D 125689856 (119MB)=0A> ne= xus0: =0A> clock0: on nexus0=0A>= clock0: [FILTER]=0A> apb0 at irq 4 on nexus0=0A> apb0: [FILTER]=0A> uart0:= <16550 or compatible> on apb0=0A> uart0: [FILTER]=0A> uart0: console (1152= 00,n,8,1)=0A> pcib0 at irq 0 on nexus0=0A> pcib0: [FILTER]=0A> pci0: on pcib0=0A> pci0: at device 0.0 (no=0A> = driver attached)=0A> pci0: at device 17.0 (no driver=0A> attach= ed)=0A> arge0: =0A> at mem=0A> = 0x19000000-0x19000fff irq 2 on nexus0=0A> miibus0: on arge0=0A> u= kphy0: PHY 4=0A> on miibus0=0A> ukphy= 0:=A0 10baseT, 10baseT-FDX, 100baseTX,=0A> 100baseTX-FDX, 1000baseT-FDX,=0A= > auto=0A> arge0: Ethernet address: 00:00:00:00:46:61=0A> arge0: [FILTER+IT= HREAD]=0A> arge1: =0A> at mem= =0A> 0x1a000000-0x1a000fff irq 3 on nexus0=0A> arge1: Ethernet address: 00:= 00:00:00:46:62=0A> arge1: [FILTER+ITHREAD]=0A> spi0: at mem 0x= 1f000000-0x1f00000f on=0A> nexus0=0A> spibus0: on spi0=0A> mx2= 5l0: at cs 0 on spibus0=0A> mx25l0: mx25ll128, sector= 65536 bytes, 256 sectors=0A> ar71xx_wdog0: = on=0A> nexus0=0A> Timecounter "MIPS32" frequency 360000000 Hz quality 800= =0A> Timecounters tick every 1.000 msec=0A> bootpc_init: wired to interface= 'arge0'=0A> Sending DHCP Discover packet from interface arge0=0A> (00:00:0= 0:00:46:61)=0A> arge0: link state changed to DOWN=0A> Trap cause =3D 2 (TLB= miss (load or instr. fetch) - kernel=0A> mode)=0A> [thread pid 4 tid 10000= 8 ]=0A> Stopped at=A0 =A0 =A0=0A> _thread_lock_flags+0x150:=A0 =A0=0A> =A0= =A0=A0lw=A0 =A0 =A0 v0,60(a3)=0A> db> bt=0A> Tracing pid 4 tid 100008 td 0x= c0c414e0=0A> db_trace_thread+30 (?,?,?,?) ra 80055900 sz 24=0A> 800557e4+11= c (0,?,ffffffff,?) ra 800552f4 sz 32=0A> 80054f60+394 (?,?,?,?) ra 80055484= sz 168=0A> db_command_loop+78 (?,?,?,?) ra 80057b58 sz 24=0A> 80057a50+108= (?,?,?,?) ra 8017b7d8 sz 424=0A> kdb_trap+f8 (?,?,?,?) ra 8035ab40 sz 32= =0A> trap+134c (?,?,?,?) ra 80351fec sz 176=0A> MipsKernGenException+100 (b= ,173,8039ce74,deadc0d8) ra=0A> 8012c92c sz 200=0A> _thread_lock_flags+130 (= ?,?,?,?) ra 801876f8 sz 56=0A> sleepq_broadcast+ac (?,?,?,?) ra 8014b700 sz= 40=0A> wakeup+2c (?,?,?,?) ra 800d6ba8 sz 32=0A> g_io_deliver+198 (?,?,?,?= ) ra 800d4964 sz 80=0A> 800d4320+644 (?,?,?,?) ra 800d6f14 sz 104=0A> g_io_= schedule_down+2ec (?,?,?,?) ra 800d7924 sz 64=0A> 800d78a8+7c (?,?,?,?) ra = 8010c0ac sz 24=0A> fork_exit+a0 (?,?,?,?) ra 8035f700 sz 48=0A> fork_trampo= line+10 (?,?,?,?) ra 0 sz 0=0A> pid 4=0A> -------------------------- schnap= p=0A> --------------------------=0A> =0A> =0A> =0A> =0A> Flo=0A> =0A> _____= __________________________________________=0A> freebsd-mips@freebsd.org=0A>= mailing list=0A> http://lists.freebsd.org/mailman/listinfo/freebsd-mips=0A= > To unsubscribe, send any mail to "freebsd-mips-unsubscribe@freebsd.org"= =0A> =0A=0A=0A From owner-freebsd-mips@FreeBSD.ORG Mon Jan 25 16:35:50 2010 Return-Path: Delivered-To: freebsd-mips@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 02AB8106566B for ; Mon, 25 Jan 2010 16:35:50 +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 9215E8FC13 for ; Mon, 25 Jan 2010 16:35:49 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.3/8.14.1) with ESMTP id o0PGUa8d049352; Mon, 25 Jan 2010 09:30:36 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Mon, 25 Jan 2010 09:31:25 -0700 (MST) Message-Id: <20100125.093125.200754749998835802.imp@bsdimp.com> To: neelnatu@yahoo.com From: "M. Warner Losh" In-Reply-To: <434364.57659.qm@web34405.mail.mud.yahoo.com> References: <1264351951.2647.93.camel@brain.lan.terror.local> <434364.57659.qm@web34405.mail.mud.yahoo.com> X-Mailer: Mew version 6.3 on Emacs 22.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-mips@FreeBSD.org Subject: Re: AR71XX RTC X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jan 2010 16:35:50 -0000 In message: <434364.57659.qm@web34405.mail.mud.yahoo.com> Neelkanth Natu writes: : Hi Flo, : = : Can you try the following patch and see if it helps with the = : hang-followed-by-trap problem? : = : I am seeing a similar problem on the Sibyte and this patch gets me : past it. : = : best : Neel : = : Index: swtch.S : =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D : --- swtch.S (revision 202961) : +++ swtch.S (working copy) : @@ -323,7 +323,7 @@ : * to be saved with the other registers do so here. : */ : = : - sw a3, TD_LOCK(a0) # Switchout td_lock = : + sw a2, TD_LOCK(a3) # Switchout td_lock = : = : mips_sw1: : #if defined(SMP) && defined(SCHED_ULE) I really like this patch. For the OCTEON I went from having all kinds of head-scratcher problems on boot that I was about to look at instruction traces in the simulator to try to track down to an immediate mountroot> prompt. So after reading the code, my first reaction is "how the heck did the old code work as well as it did?" and my second reaction is "This is obviously the right fix since a3 is a saved copy of a0, and a0 points to the pcb at this point, not the old thread." I've touched up the comments a bit. Maybe the register assignments is a bit of overkill, but this is a complicated function that's very tricky. What do you think of this patch: Index: sys/mips/mips/swtch.S =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- sys/mips/mips/swtch.S (revision 202867) +++ sys/mips/mips/swtch.S (working copy) @@ -282,9 +282,10 @@ END(mips_cpu_throw) = /* - *XXX Fixme: should be written to new interface that requires lock - * storage. We fake it for now. - * cpu_switch(struct thread *old, struct thread *new); + * cpu_switch(struct thread *old, struct thread *new, struct mutex *mt= x); + * a0 - old + * a1 - new + * a2 - mtx * Find the highest priority process and resume it. */ NON_LEAF(cpu_switch, STAND_FRAME_SIZE, ra) @@ -323,7 +324,7 @@ * to be saved with the other registers do so here. */ = - sw a3, TD_LOCK(a0) # Switchout td_lock = + sw a2, TD_LOCK(a3) # Switchout td_lock = = mips_sw1: #if defined(SMP) && defined(SCHED_ULE) Thanks for saving me hours of debugging. :) Warner : --- On Sun, 1/24/10, Florian Kruegl wrote: : = : > From: Florian Kruegl : > Subject: Re: AR71XX RTC : > To: "Oleksandr Tymoshenko" : > Cc: freebsd-mips@freebsd.org : > Date: Sunday, January 24, 2010, 8:52 AM : > Hi, : > = : > On Sun, 2010-01-24 at 02:41 +0100, Florian Kruegl wrote: : > > On Sat, 2010-01-23 at 16:53 -0800, Oleksandr : > Tymoshenko wrote: : > > > On 2010-01-23, at 4:44 PM, Florian Kruegl wrote: : > > > = : > > > > Hi, : > > > > = : > > > > On Sat, 2010-01-23 at 16:21 -0800, Oleksandr : > Tymoshenko wrote: : > > > >> On 2010-01-23, at 4:00 PM, Florian : > Kruegl wrote: : > > > >> = : > > > >>> Hi, : > > > >>> = : > > > >>> anyone working on pfc2123 driver for : > RouterStation Pro? = : > > > >>> Seems quite well documented, one : > issue might be CS hack, but the rest : > > > >>> should be straight. : > > > >>=A0 =A0 Driver was commited : > yesterday: : > > > >> http://svn.freebsd.org/viewvc/base?view=3Drevision&revision=3D= 202839 : > > > >> = : > > > >> And yes, CS hack is the problem. I'm : > trying to figure out how to fit it into FreeBSD : > > > >> SPI framework. = : > > > > = : > > > > sounds good, will do an update as soon as i : > removed me work from code. : > > > > My CS "solution" was more than crude, but : > the frames simply didn't : > > > > fit... so I am looking forward for a : > different one :) = : > > > = : > > >=A0 =A0=A0=A0Yeah, my CS solution was : > dirty hack too. If for "didn't fit" you mean missing last = : > > > byte of frame then this problem was solved to. : > Bug was in AR71XX SPI code: falling = : > > > edge was not provided for last byte in transfer : > in time and RTC chip acts of falling edge. = : > > > Fix was committed before driver. : > > > = : > > > = : > > > = : > > = : > > code looks similar, can't tell much about result as : > kernel hangs for a : > > while before getting this: : > > : > <<<<<<<<<<<<<<<<<<<<<<<<<<< : > schnipp : > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> : > > Trap cause =3D 2 (TLB miss (load or instr. fetch) - : > kernel mode) : > > [thread pid 4 tid 100009 ] : > > Stopped at=A0 =A0 =A0 : > _thread_lock_flags+0x150:=A0 =A0 : > =A0=A0=A0lw=A0 =A0 =A0 v0,60(a3) : > > db> bt : > > Tracing pid 4 tid 100009 td 0xc0c47270 : > > db_trace_thread+30 (?,?,?,?) ra 800a6c10 sz 24 : > > 800a6af4+11c (0,?,ffffffff,?) ra 800a6604 sz 32 : > > 800a6270+394 (?,?,?,?) ra 800a6794 sz 168 : > > db_command_loop+78 (?,?,?,?) ra 800a8e68 sz 24 : > > 800a8d60+108 (?,?,?,?) ra 80215ff8 sz 424 : > > kdb_trap+f8 (?,?,?,?) ra 80474350 sz 32 : > > trap+134c (?,?,?,?) ra 8046b7fc sz 176 : > > MipsKernGenException+100 (b,173,804d5de8,deadc0d8) ra : > 801c593c sz 200 : > > _thread_lock_flags+130 (?,?,?,?) ra 80221f18 sz 56 : > > sleepq_broadcast+ac (?,?,?,?) ra 801e5f20 sz 40 : > > wakeup+2c (?,?,?,?) ra 8016de18 sz 32 : > > g_io_deliver+198 (?,?,?,?) ra 8016bbd4 sz 80 : > > 8016b590+644 (?,?,?,?) ra 8016e184 sz 104 : > > g_io_schedule_down+2ec (?,?,?,?) ra 8016eb94 sz 64 : > > 8016eb18+7c (?,?,?,?) ra 801a331c sz 24 : > > fork_exit+a0 (?,?,?,?) ra 80478f10 sz 48 : > > fork_trampoline+10 (?,?,?,?) ra 0 sz 0 : > > pid 4 : > > : > <<<<<<<<<<<<<<<<<<<<<<<<<<< : > schnapp : > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> : > > = : > > will use AR71XX as config file tomorrow, mine has many : > additional devs : > > configured for booting from usb devices. : > > = : > [...] : > = : > seems to make no difference. removed all mini pci : > devs=A0 and most code : > changes. kernel hangs during bootup for a while. then gets : > a trap. = : > = : > Source Info: : > = : > -------------------------- schnipp : > -------------------------- : > brain:head> svn info : > Path: . : > URL: svn://svn.freebsd.org/base/head : > Repository Root: svn://svn.freebsd.org/base : > Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f : > Revision: 202904 : > Node Kind: directory : > Schedule: normal : > Last Changed Author: marcel : > Last Changed Rev: 202904 : > Last Changed Date: 2010-01-24 00:16:50 +0100 (Sun, 24 Jan : > 2010) : > -------------------------- schnapp : > -------------------------- : > = : > -------------------------- schnipp : > -------------------------- : > brain:head> svn stat : > ?=A0 =A0 =A0=A0=A0GRTAGS : > ?=A0 =A0 =A0=A0=A0GSYMS : > ?=A0 =A0 =A0=A0=A0GTAGS : > ?=A0 =A0 =A0=A0=A0GPATH : > M=A0 =A0 =A0=A0=A0sys/kern/vfs_mount.c : > M=A0 =A0 =A0=A0=A0sys/mips/conf/AR71XX : > ?=A0 =A0 =A0=A0=A0sys/dev/pfc2123 : > -------------------------- schnapp : > -------------------------- : > = : > - vfs_mount should be far away. = : > - sys/dev/pfc2123 is no longer used. : > - sys/mips/conf/AR71XX altered to include pfc2123_rtc : > = : > = : > -------------------------- schnipp : > -------------------------- : > FreeBSD 9.0-CURRENT #1: Sun Jan 24 15:58:37 UTC 2010 : > = : > root@pinky.lan.terror.local:/home/smeagle/obj/mips/mips/home/smeagl= e/src/freebsd/head/sys/AR71XX : > mips : > real memory=A0 =3D 134217728 (131072K bytes) : > avail memory =3D 125689856 (119MB) : > nexus0: : > clock0: on nexus0 : > clock0: [FILTER] : > apb0 at irq 4 on nexus0 : > apb0: [FILTER] : > uart0: <16550 or compatible> on apb0 : > uart0: [FILTER] : > uart0: console (115200,n,8,1) : > pcib0 at irq 0 on nexus0 : > pcib0: [FILTER] : > pci0: on pcib0 : > pci0: at device 0.0 (no : > driver attached) : > pci0: at device 17.0 (no driver : > attached) : > arge0: : > at mem : > 0x19000000-0x19000fff irq 2 on nexus0 : > miibus0: on arge0 : > ukphy0: PHY 4 : > on miibus0 : > ukphy0:=A0 10baseT, 10baseT-FDX, 100baseTX, : > 100baseTX-FDX, 1000baseT-FDX, : > auto : > arge0: Ethernet address: 00:00:00:00:46:61 : > arge0: [FILTER+ITHREAD] : > arge1: : > at mem : > 0x1a000000-0x1a000fff irq 3 on nexus0 : > arge1: Ethernet address: 00:00:00:00:46:62 : > arge1: [FILTER+ITHREAD] : > spi0: at mem 0x1f000000-0x1f00000f on : > nexus0 : > spibus0: on spi0 : > mx25l0: at cs 0 on spibus0 : > mx25l0: mx25ll128, sector 65536 bytes, 256 sectors : > ar71xx_wdog0: on : > nexus0 : > Timecounter "MIPS32" frequency 360000000 Hz quality 800 : > Timecounters tick every 1.000 msec : > bootpc_init: wired to interface 'arge0' : > Sending DHCP Discover packet from interface arge0 : > (00:00:00:00:46:61) : > arge0: link state changed to DOWN : > Trap cause =3D 2 (TLB miss (load or instr. fetch) - kernel : > mode) : > [thread pid 4 tid 100008 ] : > Stopped at=A0 =A0 =A0 : > _thread_lock_flags+0x150:=A0 =A0 : > =A0=A0=A0lw=A0 =A0 =A0 v0,60(a3) : > db> bt : > Tracing pid 4 tid 100008 td 0xc0c414e0 : > db_trace_thread+30 (?,?,?,?) ra 80055900 sz 24 : > 800557e4+11c (0,?,ffffffff,?) ra 800552f4 sz 32 : > 80054f60+394 (?,?,?,?) ra 80055484 sz 168 : > db_command_loop+78 (?,?,?,?) ra 80057b58 sz 24 : > 80057a50+108 (?,?,?,?) ra 8017b7d8 sz 424 : > kdb_trap+f8 (?,?,?,?) ra 8035ab40 sz 32 : > trap+134c (?,?,?,?) ra 80351fec sz 176 : > MipsKernGenException+100 (b,173,8039ce74,deadc0d8) ra : > 8012c92c sz 200 : > _thread_lock_flags+130 (?,?,?,?) ra 801876f8 sz 56 : > sleepq_broadcast+ac (?,?,?,?) ra 8014b700 sz 40 : > wakeup+2c (?,?,?,?) ra 800d6ba8 sz 32 : > g_io_deliver+198 (?,?,?,?) ra 800d4964 sz 80 : > 800d4320+644 (?,?,?,?) ra 800d6f14 sz 104 : > g_io_schedule_down+2ec (?,?,?,?) ra 800d7924 sz 64 : > 800d78a8+7c (?,?,?,?) ra 8010c0ac sz 24 : > fork_exit+a0 (?,?,?,?) ra 8035f700 sz 48 : > fork_trampoline+10 (?,?,?,?) ra 0 sz 0 : > pid 4 : > -------------------------- schnapp : > -------------------------- : > = : > = : > = : > = : > Flo : > = : > _______________________________________________ : > freebsd-mips@freebsd.org : > mailing list : > http://lists.freebsd.org/mailman/listinfo/freebsd-mips : > To unsubscribe, send any mail to "freebsd-mips-unsubscribe@freebsd.= org" : > = : = : = : = : _______________________________________________ : freebsd-mips@freebsd.org mailing list : http://lists.freebsd.org/mailman/listinfo/freebsd-mips : To unsubscribe, send any mail to "freebsd-mips-unsubscribe@freebsd.or= g" : = : = From owner-freebsd-mips@FreeBSD.ORG Mon Jan 25 20:41:34 2010 Return-Path: Delivered-To: freebsd-mips@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 89A74106568F for ; Mon, 25 Jan 2010 20:41:34 +0000 (UTC) (envelope-from neelnatu@yahoo.com) Received: from web34404.mail.mud.yahoo.com (web34404.mail.mud.yahoo.com [66.163.178.153]) by mx1.freebsd.org (Postfix) with SMTP id 3F9A88FC1C for ; Mon, 25 Jan 2010 20:41:34 +0000 (UTC) Received: (qmail 5659 invoked by uid 60001); 25 Jan 2010 20:41:33 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1264452093; bh=kG9kTr7ADIZhSLni3K8owhB2FTuPEkws1MlUy5CUbUc=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=zwOOOvUAUEEcDJrU3mHLLbdWwEfZLfPsckwnhRNzRw8unv5E8F4k43XhzKUlN829lCi2aUZVa2Ky3wDWvNP+dyn0Qqywf50EJv6LLoHkp6UZ/fP6zQH3sn8Iyf2/KIquPCwEvXwkjXT2OsZR9Thq1JZYaxRaxdkrOKGE2XLuPbs= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=I6TnPzJ22H2MTmFnY0QGgHCjEyz/5LZjnmzS2kEm5PWRenS64pSshbcfZObxsz+peo2zqDncWtUOFXVOyKfPX9tunr1MkpgnuG09a72lbextETLB4DinIvHDv4hdB/vYUvVaQrwV6OzDNEblr5HPWDiJQwQUfcF1OJFtVNz4ztE=; Message-ID: <832529.2466.qm@web34404.mail.mud.yahoo.com> X-YMail-OSG: BdVgsQkVM1mudnNr3klOQCn5REhSe7rBl188LzKGThlApPHuYqspc4b4uq0GbFqz5Twgz24e2IiCFQbvAN.YNqd_wGVEpsV76SBoyxrKxpHR88zjlXDYAajmKU6kRPMgBqMTiVgz6HNA6..nzqY42qJ7Hnk79Rlhv0jg8LSSv.ciLuuDa7rJC39hc9slDOIH6aZt_cZDd.AS9UNHcscbvl17Oc71cI.AqBCjnNUVMowBrje34W.DYfwsZXFpUhlaDloD34JRGHqsoKStByX2n95.cgSZ760Sbwy0zrZ6592WFjcpUHsNRxNNtg_PM4JGQjwayEc8QFRsS2JuE5tMA8DXVQSA8UzfpvilBNFI6WtpKFMbgDJcjKOevVUJHEVyCTS4Jn_Gf0V06PbSF7AaF6v00_syahV6XRQvwAEgr8fT Received: from [198.95.226.228] by web34404.mail.mud.yahoo.com via HTTP; Mon, 25 Jan 2010 12:41:33 PST X-Mailer: YahooMailClassic/9.1.10 YahooMailWebService/0.8.100.260964 Date: Mon, 25 Jan 2010 12:41:33 -0800 (PST) From: Neelkanth Natu To: "M. Warner Losh" In-Reply-To: <20100125.093125.200754749998835802.imp@bsdimp.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: freebsd-mips@FreeBSD.org Subject: Re: AR71XX RTC X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jan 2010 20:41:34 -0000 Hi Warner, The patch looks good. Please commit it. The reason we started seeing this recently is because of this: http://svn.freebsd.org/viewvc/base/head/sys/kern/sched_4bsd.c?r1=202889&r2=202888&pathrev=202889 In particular the call to thread_block_lock() will point 'td_lock' to 'blocked_lock' and if we don't switch it back in cpu_switch() then anybody trying to call thread_lock() on the thread will panic. best Neel --- On Mon, 1/25/10, M. Warner Losh wrote: > From: M. Warner Losh > Subject: Re: AR71XX RTC > To: neelnatu@yahoo.com > Cc: gonzo@bluezbox.com, smeagle@bsdler.de, freebsd-mips@FreeBSD.org > Date: Monday, January 25, 2010, 8:31 AM > In message: <434364.57659.qm@web34405.mail.mud.yahoo.com> > Neelkanth Natu > > writes: > : Hi Flo, > : > : Can you try the following patch and see if it helps with > the > : hang-followed-by-trap problem? > : > : I am seeing a similar problem on the Sibyte and this > patch gets me > : past it. > : > : best > : Neel > : > : Index: swtch.S > : > =================================================================== > : --- swtch.S (revision 202961) > : +++ swtch.S (working copy) > : @@ -323,7 +323,7 @@ > : * to be saved with > the other registers do so here. > : */ > : > : - sw a3, > TD_LOCK(a0) > # Switchout td_lock > : + sw a2, > TD_LOCK(a3) > # Switchout td_lock > : > : mips_sw1: > : #if defined(SMP) && defined(SCHED_ULE) > > I really like this patch. For the OCTEON I went from > having all kinds > of head-scratcher problems on boot that I was about to look > at > instruction traces in the simulator to try to track down to > an > immediate mountroot> prompt. So after reading the > code, my first > reaction is "how the heck did the old code work as well as > it did?" > and my second reaction is "This is obviously the right fix > since a3 is > a saved copy of a0, and a0 points to the pcb at this point, > not the > old thread." > > I've touched up the comments a bit. Maybe the > register assignments is > a bit of overkill, but this is a complicated function > that's very > tricky. What do you think of this patch: > > Index: sys/mips/mips/swtch.S > =================================================================== > --- sys/mips/mips/swtch.S (revision > 202867) > +++ sys/mips/mips/swtch.S (working copy) > @@ -282,9 +282,10 @@ > END(mips_cpu_throw) > > /* > - *XXX Fixme: should be written to new > interface that requires lock > - * storage. We > fake it for now. > - * cpu_switch(struct thread *old, struct thread *new); > + * cpu_switch(struct thread *old, struct thread *new, > struct mutex *mtx); > + * a0 - old > + * a1 - new > + * a2 - mtx > * Find the highest priority process and resume it. > */ > NON_LEAF(cpu_switch, STAND_FRAME_SIZE, ra) > @@ -323,7 +324,7 @@ > * to be saved with the other > registers do so here. > */ > > - sw a3, > TD_LOCK(a0) > # Switchout td_lock > + sw a2, > TD_LOCK(a3) > # Switchout td_lock > > mips_sw1: > #if defined(SMP) && defined(SCHED_ULE) > > > Thanks for saving me hours of debugging. :) > > Warner > > > : --- On Sun, 1/24/10, Florian Kruegl > wrote: > : > : > From: Florian Kruegl > : > Subject: Re: AR71XX RTC > : > To: "Oleksandr Tymoshenko" > : > Cc: freebsd-mips@freebsd.org > : > Date: Sunday, January 24, 2010, 8:52 AM > : > Hi, > : > > : > On Sun, 2010-01-24 at 02:41 +0100, Florian Kruegl > wrote: > : > > On Sat, 2010-01-23 at 16:53 -0800, Oleksandr > : > Tymoshenko wrote: > : > > > On 2010-01-23, at 4:44 PM, Florian Kruegl > wrote: > : > > > > : > > > > Hi, > : > > > > > : > > > > On Sat, 2010-01-23 at 16:21 -0800, > Oleksandr > : > Tymoshenko wrote: > : > > > >> On 2010-01-23, at 4:00 PM, > Florian > : > Kruegl wrote: > : > > > >> > : > > > >>> Hi, > : > > > >>> > : > > > >>> anyone working on pfc2123 > driver for > : > RouterStation Pro? > : > > > >>> Seems quite well documented, > one > : > issue might be CS hack, but the rest > : > > > >>> should be straight. > : > > > >> Driver was commited > : > yesterday: > : > > > >> http://svn.freebsd.org/viewvc/base?view=revision&revision=202839 > : > > > >> > : > > > >> And yes, CS hack is the problem. > I'm > : > trying to figure out how to fit it into FreeBSD > : > > > >> SPI framework. > : > > > > > : > > > > sounds good, will do an update as > soon as i > : > removed me work from code. > : > > > > My CS "solution" was more than crude, > but > : > the frames simply didn't > : > > > > fit... so I am looking forward for a > : > different one :) > : > > > > : > > > Yeah, my CS solution was > : > dirty hack too. If for "didn't fit" you mean missing > last > : > > > byte of frame then this problem was solved > to. > : > Bug was in AR71XX SPI code: falling > : > > > edge was not provided for last byte in > transfer > : > in time and RTC chip acts of falling edge. > : > > > Fix was committed before driver. > : > > > > : > > > > : > > > > : > > > : > > code looks similar, can't tell much about > result as > : > kernel hangs for a > : > > while before getting this: > : > > > : > > <<<<<<<<<<<<<<<<<<<<<<<<<<< > : > schnipp > : > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > : > > Trap cause = 2 (TLB miss (load or instr. fetch) > - > : > kernel mode) > : > > [thread pid 4 tid 100009 ] > : > > Stopped at > : > _thread_lock_flags+0x150: > : > lw v0,60(a3) > : > > db> bt > : > > Tracing pid 4 tid 100009 td 0xc0c47270 > : > > db_trace_thread+30 (?,?,?,?) ra 800a6c10 sz 24 > : > > 800a6af4+11c (0,?,ffffffff,?) ra 800a6604 sz > 32 > : > > 800a6270+394 (?,?,?,?) ra 800a6794 sz 168 > : > > db_command_loop+78 (?,?,?,?) ra 800a8e68 sz 24 > : > > 800a8d60+108 (?,?,?,?) ra 80215ff8 sz 424 > : > > kdb_trap+f8 (?,?,?,?) ra 80474350 sz 32 > : > > trap+134c (?,?,?,?) ra 8046b7fc sz 176 > : > > MipsKernGenException+100 > (b,173,804d5de8,deadc0d8) ra > : > 801c593c sz 200 > : > > _thread_lock_flags+130 (?,?,?,?) ra 80221f18 sz > 56 > : > > sleepq_broadcast+ac (?,?,?,?) ra 801e5f20 sz > 40 > : > > wakeup+2c (?,?,?,?) ra 8016de18 sz 32 > : > > g_io_deliver+198 (?,?,?,?) ra 8016bbd4 sz 80 > : > > 8016b590+644 (?,?,?,?) ra 8016e184 sz 104 > : > > g_io_schedule_down+2ec (?,?,?,?) ra 8016eb94 sz > 64 > : > > 8016eb18+7c (?,?,?,?) ra 801a331c sz 24 > : > > fork_exit+a0 (?,?,?,?) ra 80478f10 sz 48 > : > > fork_trampoline+10 (?,?,?,?) ra 0 sz 0 > : > > pid 4 > : > > > : > > <<<<<<<<<<<<<<<<<<<<<<<<<<< > : > schnapp > : > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > : > > > : > > will use AR71XX as config file tomorrow, mine > has many > : > additional devs > : > > configured for booting from usb devices. > : > > > : > [...] > : > > : > seems to make no difference. removed all mini pci > : > devs and most code > : > changes. kernel hangs during bootup for a while. > then gets > : > a trap. > : > > : > Source Info: > : > > : > -------------------------- schnipp > : > -------------------------- > : > brain:head> svn info > : > Path: . > : > URL: svn://svn.freebsd.org/base/head > : > Repository Root: svn://svn.freebsd.org/base > : > Repository UUID: > ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f > : > Revision: 202904 > : > Node Kind: directory > : > Schedule: normal > : > Last Changed Author: marcel > : > Last Changed Rev: 202904 > : > Last Changed Date: 2010-01-24 00:16:50 +0100 (Sun, > 24 Jan > : > 2010) > : > -------------------------- schnapp > : > -------------------------- > : > > : > -------------------------- schnipp > : > -------------------------- > : > brain:head> svn stat > : > ? GRTAGS > : > ? GSYMS > : > ? GTAGS > : > ? GPATH > : > M sys/kern/vfs_mount.c > : > M sys/mips/conf/AR71XX > : > ? sys/dev/pfc2123 > : > -------------------------- schnapp > : > -------------------------- > : > > : > - vfs_mount should be far away. > : > - sys/dev/pfc2123 is no longer used. > : > - sys/mips/conf/AR71XX altered to include > pfc2123_rtc > : > > : > > : > -------------------------- schnipp > : > -------------------------- > : > FreeBSD 9.0-CURRENT #1: Sun Jan 24 15:58:37 UTC > 2010 > : > > : > root@pinky.lan.terror.local:/home/smeagle/obj/mips/mips/home/smeagle/src/freebsd/head/sys/AR71XX > : > mips > : > real memory = 134217728 (131072K bytes) > : > avail memory = 125689856 (119MB) > : > nexus0: > : > clock0: on nexus0 > : > clock0: [FILTER] > : > apb0 at irq 4 on nexus0 > : > apb0: [FILTER] > : > uart0: <16550 or compatible> on apb0 > : > uart0: [FILTER] > : > uart0: console (115200,n,8,1) > : > pcib0 at irq 0 on nexus0 > : > pcib0: [FILTER] > : > pci0: on pcib0 > : > pci0: at device > 0.0 (no > : > driver attached) > : > pci0: at device 17.0 (no driver > : > attached) > : > arge0: interface> > : > at mem > : > 0x19000000-0x19000fff irq 2 on nexus0 > : > miibus0: on arge0 > : > ukphy0: > PHY 4 > : > on miibus0 > : > ukphy0: 10baseT, 10baseT-FDX, 100baseTX, > : > 100baseTX-FDX, 1000baseT-FDX, > : > auto > : > arge0: Ethernet address: 00:00:00:00:46:61 > : > arge0: [FILTER+ITHREAD] > : > arge1: interface> > : > at mem > : > 0x1a000000-0x1a000fff irq 3 on nexus0 > : > arge1: Ethernet address: 00:00:00:00:46:62 > : > arge1: [FILTER+ITHREAD] > : > spi0: at mem > 0x1f000000-0x1f00000f on > : > nexus0 > : > spibus0: on spi0 > : > mx25l0: at cs 0 on > spibus0 > : > mx25l0: mx25ll128, sector 65536 bytes, 256 sectors > : > ar71xx_wdog0: > on > : > nexus0 > : > Timecounter "MIPS32" frequency 360000000 Hz quality > 800 > : > Timecounters tick every 1.000 msec > : > bootpc_init: wired to interface 'arge0' > : > Sending DHCP Discover packet from interface arge0 > : > (00:00:00:00:46:61) > : > arge0: link state changed to DOWN > : > Trap cause = 2 (TLB miss (load or instr. fetch) - > kernel > : > mode) > : > [thread pid 4 tid 100008 ] > : > Stopped at > : > _thread_lock_flags+0x150: > : > lw v0,60(a3) > : > db> bt > : > Tracing pid 4 tid 100008 td 0xc0c414e0 > : > db_trace_thread+30 (?,?,?,?) ra 80055900 sz 24 > : > 800557e4+11c (0,?,ffffffff,?) ra 800552f4 sz 32 > : > 80054f60+394 (?,?,?,?) ra 80055484 sz 168 > : > db_command_loop+78 (?,?,?,?) ra 80057b58 sz 24 > : > 80057a50+108 (?,?,?,?) ra 8017b7d8 sz 424 > : > kdb_trap+f8 (?,?,?,?) ra 8035ab40 sz 32 > : > trap+134c (?,?,?,?) ra 80351fec sz 176 > : > MipsKernGenException+100 (b,173,8039ce74,deadc0d8) > ra > : > 8012c92c sz 200 > : > _thread_lock_flags+130 (?,?,?,?) ra 801876f8 sz 56 > : > sleepq_broadcast+ac (?,?,?,?) ra 8014b700 sz 40 > : > wakeup+2c (?,?,?,?) ra 800d6ba8 sz 32 > : > g_io_deliver+198 (?,?,?,?) ra 800d4964 sz 80 > : > 800d4320+644 (?,?,?,?) ra 800d6f14 sz 104 > : > g_io_schedule_down+2ec (?,?,?,?) ra 800d7924 sz 64 > : > 800d78a8+7c (?,?,?,?) ra 8010c0ac sz 24 > : > fork_exit+a0 (?,?,?,?) ra 8035f700 sz 48 > : > fork_trampoline+10 (?,?,?,?) ra 0 sz 0 > : > pid 4 > : > -------------------------- schnapp > : > -------------------------- > : > > : > > : > > : > > : > Flo > : > > : > _______________________________________________ > : > freebsd-mips@freebsd.org > : > mailing list > : > http://lists.freebsd.org/mailman/listinfo/freebsd-mips > : > To unsubscribe, send any mail to "freebsd-mips-unsubscribe@freebsd.org" > : > > : > : > : > : _______________________________________________ > : freebsd-mips@freebsd.org > mailing list > : http://lists.freebsd.org/mailman/listinfo/freebsd-mips > : To unsubscribe, send any mail to "freebsd-mips-unsubscribe@freebsd.org" > : > : > From owner-freebsd-mips@FreeBSD.ORG Mon Jan 25 20:52:53 2010 Return-Path: Delivered-To: freebsd-mips@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8EBBE1065672 for ; Mon, 25 Jan 2010 20:52:53 +0000 (UTC) (envelope-from rrs@lakerest.net) Received: from lakerest.net (unknown [IPv6:2001:240:585:2:213:d4ff:fef3:2d8d]) by mx1.freebsd.org (Postfix) with ESMTP id 09C2E8FC19 for ; Mon, 25 Jan 2010 20:52:52 +0000 (UTC) Received: from mobile-166-129-165-043.mycingular.net (mobile-166-129-165-043.mycingular.net [166.129.165.43] (may be forged)) (authenticated bits=0) by lakerest.net (8.14.3/8.14.3) with ESMTP id o0PKpZjS099431 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 25 Jan 2010 15:52:07 -0500 (EST) (envelope-from rrs@lakerest.net) Message-Id: <5D3E417C-FE51-49A7-B8CC-564932BF0D3E@lakerest.net> From: Randall Stewart To: Neelkanth Natu In-Reply-To: <832529.2466.qm@web34404.mail.mud.yahoo.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 25 Jan 2010 12:51:29 -0800 References: <832529.2466.qm@web34404.mail.mud.yahoo.com> X-Mailer: Apple Mail (2.936) Cc: freebsd-mips@freebsd.org Subject: Re: AR71XX RTC X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jan 2010 20:52:53 -0000 Neil: Thanks for the patch.. it does look good since the old code was tromping part of the old threads PCB which is definitely not right ;-0 .. I do have a question for you.. forgive my ignorance.. What exactly are we trying to switch here. It seems that cpu_switch(...) is now being called with oldtd, newtd and mtx... I see that the thread structure has a struct mutex *td_lock as its first member. But what is this supposed to be pointing to? And when we switch are we trying to take the oldtd->td_lock and place it into the newtd->td_lock Or? What... I guess I just don't have any context for whats going on.. R On Jan 25, 2010, at 12:41 PM, Neelkanth Natu wrote: > Hi Warner, > > The patch looks good. Please commit it. > > The reason we started seeing this recently is because of this: > http://svn.freebsd.org/viewvc/base/head/sys/kern/sched_4bsd.c?r1=202889&r2=202888&pathrev=202889 > > In particular the call to thread_block_lock() will point 'td_lock' to > 'blocked_lock' and if we don't switch it back in cpu_switch() then > anybody trying to call thread_lock() on the thread will panic. > > best > Neel > > --- On Mon, 1/25/10, M. Warner Losh wrote: > >> From: M. Warner Losh >> Subject: Re: AR71XX RTC >> To: neelnatu@yahoo.com >> Cc: gonzo@bluezbox.com, smeagle@bsdler.de, freebsd-mips@FreeBSD.org >> Date: Monday, January 25, 2010, 8:31 AM >> In message: <434364.57659.qm@web34405.mail.mud.yahoo.com> >> Neelkanth Natu >> >> writes: >> : Hi Flo, >> : >> : Can you try the following patch and see if it helps with >> the >> : hang-followed-by-trap problem? >> : >> : I am seeing a similar problem on the Sibyte and this >> patch gets me >> : past it. >> : >> : best >> : Neel >> : >> : Index: swtch.S >> : >> =================================================================== >> : --- swtch.S (revision 202961) >> : +++ swtch.S (working copy) >> : @@ -323,7 +323,7 @@ >> : * to be saved with >> the other registers do so here. >> : */ >> : >> : - sw a3, >> TD_LOCK(a0) >> # Switchout td_lock >> : + sw a2, >> TD_LOCK(a3) >> # Switchout td_lock >> : >> : mips_sw1: >> : #if defined(SMP) && defined(SCHED_ULE) >> >> I really like this patch. For the OCTEON I went from >> having all kinds >> of head-scratcher problems on boot that I was about to look >> at >> instruction traces in the simulator to try to track down to >> an >> immediate mountroot> prompt. So after reading the >> code, my first >> reaction is "how the heck did the old code work as well as >> it did?" >> and my second reaction is "This is obviously the right fix >> since a3 is >> a saved copy of a0, and a0 points to the pcb at this point, >> not the >> old thread." >> >> I've touched up the comments a bit. Maybe the >> register assignments is >> a bit of overkill, but this is a complicated function >> that's very >> tricky. What do you think of this patch: >> >> Index: sys/mips/mips/swtch.S >> =================================================================== >> --- sys/mips/mips/swtch.S (revision >> 202867) >> +++ sys/mips/mips/swtch.S (working copy) >> @@ -282,9 +282,10 @@ >> END(mips_cpu_throw) >> >> /* >> - *XXX Fixme: should be written to new >> interface that requires lock >> - * storage. We >> fake it for now. >> - * cpu_switch(struct thread *old, struct thread *new); >> + * cpu_switch(struct thread *old, struct thread *new, >> struct mutex *mtx); >> + * a0 - old >> + * a1 - new >> + * a2 - mtx >> * Find the highest priority process and resume it. >> */ >> NON_LEAF(cpu_switch, STAND_FRAME_SIZE, ra) >> @@ -323,7 +324,7 @@ >> * to be saved with the other >> registers do so here. >> */ >> >> - sw a3, >> TD_LOCK(a0) >> # Switchout td_lock >> + sw a2, >> TD_LOCK(a3) >> # Switchout td_lock >> >> mips_sw1: >> #if defined(SMP) && defined(SCHED_ULE) >> >> >> Thanks for saving me hours of debugging. :) >> >> Warner >> >> >> : --- On Sun, 1/24/10, Florian Kruegl >> wrote: >> : >> : > From: Florian Kruegl >> : > Subject: Re: AR71XX RTC >> : > To: "Oleksandr Tymoshenko" >> : > Cc: freebsd-mips@freebsd.org >> : > Date: Sunday, January 24, 2010, 8:52 AM >> : > Hi, >> : > >> : > On Sun, 2010-01-24 at 02:41 +0100, Florian Kruegl >> wrote: >> : > > On Sat, 2010-01-23 at 16:53 -0800, Oleksandr >> : > Tymoshenko wrote: >> : > > > On 2010-01-23, at 4:44 PM, Florian Kruegl >> wrote: >> : > > > >> : > > > > Hi, >> : > > > > >> : > > > > On Sat, 2010-01-23 at 16:21 -0800, >> Oleksandr >> : > Tymoshenko wrote: >> : > > > >> On 2010-01-23, at 4:00 PM, >> Florian >> : > Kruegl wrote: >> : > > > >> >> : > > > >>> Hi, >> : > > > >>> >> : > > > >>> anyone working on pfc2123 >> driver for >> : > RouterStation Pro? >> : > > > >>> Seems quite well documented, >> one >> : > issue might be CS hack, but the rest >> : > > > >>> should be straight. >> : > > > >> Driver was commited >> : > yesterday: >> : > > > >> http://svn.freebsd.org/viewvc/base?view=revision&revision=202839 >> : > > > >> >> : > > > >> And yes, CS hack is the problem. >> I'm >> : > trying to figure out how to fit it into FreeBSD >> : > > > >> SPI framework. >> : > > > > >> : > > > > sounds good, will do an update as >> soon as i >> : > removed me work from code. >> : > > > > My CS "solution" was more than crude, >> but >> : > the frames simply didn't >> : > > > > fit... so I am looking forward for a >> : > different one :) >> : > > > >> : > > > Yeah, my CS solution was >> : > dirty hack too. If for "didn't fit" you mean missing >> last >> : > > > byte of frame then this problem was solved >> to. >> : > Bug was in AR71XX SPI code: falling >> : > > > edge was not provided for last byte in >> transfer >> : > in time and RTC chip acts of falling edge. >> : > > > Fix was committed before driver. >> : > > > >> : > > > >> : > > > >> : > > >> : > > code looks similar, can't tell much about >> result as >> : > kernel hangs for a >> : > > while before getting this: >> : > > >> : > >> <<<<<<<<<<<<<<<<<<<<<<<<<<< >> : > schnipp >> : > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >> : > > Trap cause = 2 (TLB miss (load or instr. fetch) >> - >> : > kernel mode) >> : > > [thread pid 4 tid 100009 ] >> : > > Stopped at >> : > _thread_lock_flags+0x150: >> : > lw v0,60(a3) >> : > > db> bt >> : > > Tracing pid 4 tid 100009 td 0xc0c47270 >> : > > db_trace_thread+30 (?,?,?,?) ra 800a6c10 sz 24 >> : > > 800a6af4+11c (0,?,ffffffff,?) ra 800a6604 sz >> 32 >> : > > 800a6270+394 (?,?,?,?) ra 800a6794 sz 168 >> : > > db_command_loop+78 (?,?,?,?) ra 800a8e68 sz 24 >> : > > 800a8d60+108 (?,?,?,?) ra 80215ff8 sz 424 >> : > > kdb_trap+f8 (?,?,?,?) ra 80474350 sz 32 >> : > > trap+134c (?,?,?,?) ra 8046b7fc sz 176 >> : > > MipsKernGenException+100 >> (b,173,804d5de8,deadc0d8) ra >> : > 801c593c sz 200 >> : > > _thread_lock_flags+130 (?,?,?,?) ra 80221f18 sz >> 56 >> : > > sleepq_broadcast+ac (?,?,?,?) ra 801e5f20 sz >> 40 >> : > > wakeup+2c (?,?,?,?) ra 8016de18 sz 32 >> : > > g_io_deliver+198 (?,?,?,?) ra 8016bbd4 sz 80 >> : > > 8016b590+644 (?,?,?,?) ra 8016e184 sz 104 >> : > > g_io_schedule_down+2ec (?,?,?,?) ra 8016eb94 sz >> 64 >> : > > 8016eb18+7c (?,?,?,?) ra 801a331c sz 24 >> : > > fork_exit+a0 (?,?,?,?) ra 80478f10 sz 48 >> : > > fork_trampoline+10 (?,?,?,?) ra 0 sz 0 >> : > > pid 4 >> : > > >> : > >> <<<<<<<<<<<<<<<<<<<<<<<<<<< >> : > schnapp >> : > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >> : > > >> : > > will use AR71XX as config file tomorrow, mine >> has many >> : > additional devs >> : > > configured for booting from usb devices. >> : > > >> : > [...] >> : > >> : > seems to make no difference. removed all mini pci >> : > devs and most code >> : > changes. kernel hangs during bootup for a while. >> then gets >> : > a trap. >> : > >> : > Source Info: >> : > >> : > -------------------------- schnipp >> : > -------------------------- >> : > brain:head> svn info >> : > Path: . >> : > URL: svn://svn.freebsd.org/base/head >> : > Repository Root: svn://svn.freebsd.org/base >> : > Repository UUID: >> ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f >> : > Revision: 202904 >> : > Node Kind: directory >> : > Schedule: normal >> : > Last Changed Author: marcel >> : > Last Changed Rev: 202904 >> : > Last Changed Date: 2010-01-24 00:16:50 +0100 (Sun, >> 24 Jan >> : > 2010) >> : > -------------------------- schnapp >> : > -------------------------- >> : > >> : > -------------------------- schnipp >> : > -------------------------- >> : > brain:head> svn stat >> : > ? GRTAGS >> : > ? GSYMS >> : > ? GTAGS >> : > ? GPATH >> : > M sys/kern/vfs_mount.c >> : > M sys/mips/conf/AR71XX >> : > ? sys/dev/pfc2123 >> : > -------------------------- schnapp >> : > -------------------------- >> : > >> : > - vfs_mount should be far away. >> : > - sys/dev/pfc2123 is no longer used. >> : > - sys/mips/conf/AR71XX altered to include >> pfc2123_rtc >> : > >> : > >> : > -------------------------- schnipp >> : > -------------------------- >> : > FreeBSD 9.0-CURRENT #1: Sun Jan 24 15:58:37 UTC >> 2010 >> : > >> : > root@pinky.lan.terror.local:/home/smeagle/obj/mips/mips/home/ >> smeagle/src/freebsd/head/sys/AR71XX >> : > mips >> : > real memory = 134217728 (131072K bytes) >> : > avail memory = 125689856 (119MB) >> : > nexus0: >> : > clock0: on nexus0 >> : > clock0: [FILTER] >> : > apb0 at irq 4 on nexus0 >> : > apb0: [FILTER] >> : > uart0: <16550 or compatible> on apb0 >> : > uart0: [FILTER] >> : > uart0: console (115200,n,8,1) >> : > pcib0 at irq 0 on nexus0 >> : > pcib0: [FILTER] >> : > pci0: on pcib0 >> : > pci0: at device >> 0.0 (no >> : > driver attached) >> : > pci0: at device 17.0 (no driver >> : > attached) >> : > arge0: > interface> >> : > at mem >> : > 0x19000000-0x19000fff irq 2 on nexus0 >> : > miibus0: on arge0 >> : > ukphy0: >> PHY 4 >> : > on miibus0 >> : > ukphy0: 10baseT, 10baseT-FDX, 100baseTX, >> : > 100baseTX-FDX, 1000baseT-FDX, >> : > auto >> : > arge0: Ethernet address: 00:00:00:00:46:61 >> : > arge0: [FILTER+ITHREAD] >> : > arge1: > interface> >> : > at mem >> : > 0x1a000000-0x1a000fff irq 3 on nexus0 >> : > arge1: Ethernet address: 00:00:00:00:46:62 >> : > arge1: [FILTER+ITHREAD] >> : > spi0: at mem >> 0x1f000000-0x1f00000f on >> : > nexus0 >> : > spibus0: on spi0 >> : > mx25l0: at cs 0 on >> spibus0 >> : > mx25l0: mx25ll128, sector 65536 bytes, 256 sectors >> : > ar71xx_wdog0: >> on >> : > nexus0 >> : > Timecounter "MIPS32" frequency 360000000 Hz quality >> 800 >> : > Timecounters tick every 1.000 msec >> : > bootpc_init: wired to interface 'arge0' >> : > Sending DHCP Discover packet from interface arge0 >> : > (00:00:00:00:46:61) >> : > arge0: link state changed to DOWN >> : > Trap cause = 2 (TLB miss (load or instr. fetch) - >> kernel >> : > mode) >> : > [thread pid 4 tid 100008 ] >> : > Stopped at >> : > _thread_lock_flags+0x150: >> : > lw v0,60(a3) >> : > db> bt >> : > Tracing pid 4 tid 100008 td 0xc0c414e0 >> : > db_trace_thread+30 (?,?,?,?) ra 80055900 sz 24 >> : > 800557e4+11c (0,?,ffffffff,?) ra 800552f4 sz 32 >> : > 80054f60+394 (?,?,?,?) ra 80055484 sz 168 >> : > db_command_loop+78 (?,?,?,?) ra 80057b58 sz 24 >> : > 80057a50+108 (?,?,?,?) ra 8017b7d8 sz 424 >> : > kdb_trap+f8 (?,?,?,?) ra 8035ab40 sz 32 >> : > trap+134c (?,?,?,?) ra 80351fec sz 176 >> : > MipsKernGenException+100 (b,173,8039ce74,deadc0d8) >> ra >> : > 8012c92c sz 200 >> : > _thread_lock_flags+130 (?,?,?,?) ra 801876f8 sz 56 >> : > sleepq_broadcast+ac (?,?,?,?) ra 8014b700 sz 40 >> : > wakeup+2c (?,?,?,?) ra 800d6ba8 sz 32 >> : > g_io_deliver+198 (?,?,?,?) ra 800d4964 sz 80 >> : > 800d4320+644 (?,?,?,?) ra 800d6f14 sz 104 >> : > g_io_schedule_down+2ec (?,?,?,?) ra 800d7924 sz 64 >> : > 800d78a8+7c (?,?,?,?) ra 8010c0ac sz 24 >> : > fork_exit+a0 (?,?,?,?) ra 8035f700 sz 48 >> : > fork_trampoline+10 (?,?,?,?) ra 0 sz 0 >> : > pid 4 >> : > -------------------------- schnapp >> : > -------------------------- >> : > >> : > >> : > >> : > >> : > Flo >> : > >> : > _______________________________________________ >> : > freebsd-mips@freebsd.org >> : > mailing list >> : > http://lists.freebsd.org/mailman/listinfo/freebsd-mips >> : > To unsubscribe, send any mail to "freebsd-mips-unsubscribe@freebsd.org >> " >> : > >> : >> : >> : >> : _______________________________________________ >> : freebsd-mips@freebsd.org >> mailing list >> : http://lists.freebsd.org/mailman/listinfo/freebsd-mips >> : To unsubscribe, send any mail to "freebsd-mips-unsubscribe@freebsd.org >> " >> : >> : >> > > > > _______________________________________________ > freebsd-mips@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-mips > To unsubscribe, send any mail to "freebsd-mips- > unsubscribe@freebsd.org" > ------------------------------ Randall Stewart 803-317-4952 (cell) 803-345-0391(direct) From owner-freebsd-mips@FreeBSD.ORG Mon Jan 25 21:51:49 2010 Return-Path: Delivered-To: freebsd-mips@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9295A10656A3 for ; Mon, 25 Jan 2010 21:51:49 +0000 (UTC) (envelope-from neelnatu@yahoo.com) Received: from web34403.mail.mud.yahoo.com (web34403.mail.mud.yahoo.com [66.163.178.152]) by mx1.freebsd.org (Postfix) with SMTP id 5B5808FC24 for ; Mon, 25 Jan 2010 21:51:49 +0000 (UTC) Received: (qmail 45611 invoked by uid 60001); 25 Jan 2010 21:51:48 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1264456308; bh=RParALN6ZybvmpeXenfnfugS1jrAoRSC+24JeJifNFU=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=IDdTAJq/a6+wdKTbGckDe6PFQXFsgkCDJpNid5WSUrZ+oSMVZR+YDtgzx+l14pNDyMsj022Gh8oXYn/Y4RR+OUZOQYT3+f+0eZ/cRwPJB3F8x+NMFYqdVd9VT0QSzKKxMQYqseH8kTTbdNbK+7mFRLmKxfztbvA0P08fq4MrrrY= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=P7NNAHBNGwnnLlXjdYTnmqhOV8KrG9FkaDLATt0AwM8YI1iTq34K+FFGpUml2beIlGZL9NKVdaJ/UVgoWkG7vn2hfkx3YeygToZ7kD29S0WdLiR80L7Qmd2lStWMXxvUlQcXX1P3g3qrjaEypAZttwpFXZXlgOuSI6GO+xaRLz4=; Message-ID: <489828.45501.qm@web34403.mail.mud.yahoo.com> X-YMail-OSG: KGVjH04VM1mp6IQ7UYXsf20A.PUykewRHRpBnUcgVO8fZLW8niwQtmHXNEOtzrSmG3SEnOW3eFTBwkWWOJEnffR9yKQNma4je4eKLLfuGRvqCFxOeVRIiDWF2CuOGq1KmfKpWMUKdmyzeHC8l2ohW.saG5IZV_6qAirLA.seiJeumZXDDiV1EPQEsleEGmGHpEVeVv.qssLcM6dy9Y4l0B2M.YE4GC4Fvl8FZ6V8B11mPIS46wmsUfIDBp7S.hKp8MAruuog3IsYMi7eT97sUAiK9wWenXrljoJ_IBrJ.vEB5uBtlYdxh3HKsZSb0mHQyd.ytrkJAi3EhUpAsve.Cq3qCz3E7pLvLsduv7nSf6rMqcXakvWUXazHknNQIulRbSQ4Ko9wsDMOjlaiAFYWACTzhJStyb_m4DvaPlAZ8K36 Received: from [198.95.226.228] by web34403.mail.mud.yahoo.com via HTTP; Mon, 25 Jan 2010 13:51:48 PST X-Mailer: YahooMailClassic/9.1.10 YahooMailWebService/0.8.100.260964 Date: Mon, 25 Jan 2010 13:51:48 -0800 (PST) From: Neelkanth Natu To: Randall Stewart In-Reply-To: <5D3E417C-FE51-49A7-B8CC-564932BF0D3E@lakerest.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: attilio@freebsd.org, freebsd-mips@freebsd.org Subject: Re: AR71XX RTC X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jan 2010 21:51:49 -0000 Hi Randall, --- On Mon, 1/25/10, Randall Stewart wrote: > From: Randall Stewart > Subject: Re: AR71XX RTC > To: "Neelkanth Natu" > Cc: "M. Warner Losh" , freebsd-mips@freebsd.org > Date: Monday, January 25, 2010, 12:51 PM > Neil: > > Thanks for the patch.. it does look good since the old > code was tromping part of the old threads PCB which is > definitely not right ;-0 .. I do have a question for you.. > forgive my ignorance.. > > What exactly are we trying to switch here. It seems > that cpu_switch(...) is now being called with > oldtd, newtd and mtx... > > I see that the thread structure has a struct mutex *td_lock > as > its first member. But what is this supposed to be pointing > to? > And when we switch are we trying to take the > > oldtd->td_lock and place it into the newtd->td_lock > > Or? > > What... I guess I just don't have any context for whats > going on.. > I am not very sure about this myself so take this with a grain of salt: When a thread is being switched out because it is on a sleep queue the intent is that some other thread running on a different cpu should not be allowed to muck with this thread's state. To make this happen the 'td_lock' of 'oldtd' is switched from what it was originally (viz. the sleep queue chain lock) to 'blocked_lock'. The 'blocked_lock' is special because it is always locked. This all happens in sched_switch(). cpu_switch() is passed the original value of 'oldtd->td_lock' as the third argument. When the context is switched to 'newtd' we will switch back the 'oldtd->td_lock' from 'blocked_lock' to its original value. And this way we don't lose any wakeups that may happen while we are in sched_switch(). At least that is my very naive understanding of it. CCing Attilio to shed more light on this. best Neel > R > > > > On Jan 25, 2010, at 12:41 PM, Neelkanth Natu wrote: > > > Hi Warner, > > > > The patch looks good. Please commit it. > > > > The reason we started seeing this recently is because > of this: > > http://svn.freebsd.org/viewvc/base/head/sys/kern/sched_4bsd.c?r1=202889&r2=202888&pathrev=202889 > > > > In particular the call to thread_block_lock() will > point 'td_lock' to > > 'blocked_lock' and if we don't switch it back in > cpu_switch() then > > anybody trying to call thread_lock() on the thread > will panic. > > > > best > > Neel > > > > --- On Mon, 1/25/10, M. Warner Losh > wrote: > > > >> From: M. Warner Losh > >> Subject: Re: AR71XX RTC > >> To: neelnatu@yahoo.com > >> Cc: gonzo@bluezbox.com, > smeagle@bsdler.de, > freebsd-mips@FreeBSD.org > >> Date: Monday, January 25, 2010, 8:31 AM > >> In message: <434364.57659.qm@web34405.mail.mud.yahoo.com> > >> Neelkanth > Natu > >> > >> writes: > >> : Hi Flo, > >> : > >> : Can you try the following patch and see if it > helps with > >> the > >> : hang-followed-by-trap problem? > >> : > >> : I am seeing a similar problem on the Sibyte and > this > >> patch gets me > >> : past it. > >> : > >> : best > >> : Neel > >> : > >> : Index: swtch.S > >> : > >> > =================================================================== > >> : --- swtch.S (revision 202961) > >> : +++ swtch.S (working copy) > >> : @@ -323,7 +323,7 @@ > >> : * to be saved > with > >> the other registers do so here. > >> : */ > >> : > >> : - sw a3, > >> TD_LOCK(a0) > >> # Switchout td_lock > >> : + sw a2, > >> TD_LOCK(a3) > >> # Switchout td_lock > >> : > >> : mips_sw1: > >> : #if defined(SMP) && > defined(SCHED_ULE) > >> > >> I really like this patch. For the OCTEON I > went from > >> having all kinds > >> of head-scratcher problems on boot that I was > about to look > >> at > >> instruction traces in the simulator to try to > track down to > >> an > >> immediate mountroot> prompt. So after > reading the > >> code, my first > >> reaction is "how the heck did the old code work as > well as > >> it did?" > >> and my second reaction is "This is obviously the > right fix > >> since a3 is > >> a saved copy of a0, and a0 points to the pcb at > this point, > >> not the > >> old thread." > >> > >> I've touched up the comments a bit. Maybe > the > >> register assignments is > >> a bit of overkill, but this is a complicated > function > >> that's very > >> tricky. What do you think of this patch: > >> > >> Index: sys/mips/mips/swtch.S > >> > =================================================================== > >> --- sys/mips/mips/swtch.S (revision > >> 202867) > >> +++ sys/mips/mips/swtch.S (working > copy) > >> @@ -282,9 +282,10 @@ > >> END(mips_cpu_throw) > >> > >> /* > >> - *XXX Fixme: should be written to > new > >> interface that requires lock > >> - * storage. We > >> fake it for now. > >> - * cpu_switch(struct thread *old, struct thread > *new); > >> + * cpu_switch(struct thread *old, struct thread > *new, > >> struct mutex *mtx); > >> + * a0 - old > >> + * a1 - new > >> + * a2 - mtx > >> * Find the highest priority process and > resume it. > >> */ > >> NON_LEAF(cpu_switch, STAND_FRAME_SIZE, ra) > >> @@ -323,7 +324,7 @@ > >> * to be saved with the other > >> registers do so here. > >> */ > >> > >> - sw a3, > >> TD_LOCK(a0) > >> # Switchout td_lock > >> + sw a2, > >> TD_LOCK(a3) > >> # Switchout td_lock > >> > >> mips_sw1: > >> #if defined(SMP) && defined(SCHED_ULE) > >> > >> > >> Thanks for saving me hours of debugging. :) > >> > >> Warner > >> > >> > >> : --- On Sun, 1/24/10, Florian Kruegl > >> wrote: > >> : > >> : > From: Florian Kruegl > >> : > Subject: Re: AR71XX RTC > >> : > To: "Oleksandr Tymoshenko" > >> : > Cc: freebsd-mips@freebsd.org > >> : > Date: Sunday, January 24, 2010, 8:52 AM > >> : > Hi, > >> : > > >> : > On Sun, 2010-01-24 at 02:41 +0100, Florian > Kruegl > >> wrote: > >> : > > On Sat, 2010-01-23 at 16:53 -0800, > Oleksandr > >> : > Tymoshenko wrote: > >> : > > > On 2010-01-23, at 4:44 PM, > Florian Kruegl > >> wrote: > >> : > > > > >> : > > > > Hi, > >> : > > > > > >> : > > > > On Sat, 2010-01-23 at 16:21 > -0800, > >> Oleksandr > >> : > Tymoshenko wrote: > >> : > > > >> On 2010-01-23, at 4:00 > PM, > >> Florian > >> : > Kruegl wrote: > >> : > > > >> > >> : > > > >>> Hi, > >> : > > > >>> > >> : > > > >>> anyone working on > pfc2123 > >> driver for > >> : > RouterStation Pro? > >> : > > > >>> Seems quite well > documented, > >> one > >> : > issue might be CS hack, but the rest > >> : > > > >>> should be straight. > >> : > > > >> Driver was > commited > >> : > yesterday: > >> : > > > >> http://svn.freebsd.org/viewvc/base?view=revision&revision=202839 > >> : > > > >> > >> : > > > >> And yes, CS hack is the > problem. > >> I'm > >> : > trying to figure out how to fit it into > FreeBSD > >> : > > > >> SPI framework. > >> : > > > > > >> : > > > > sounds good, will do an > update as > >> soon as i > >> : > removed me work from code. > >> : > > > > My CS "solution" was more > than crude, > >> but > >> : > the frames simply didn't > >> : > > > > fit... so I am looking > forward for a > >> : > different one :) > >> : > > > > >> : > > > Yeah, my > CS solution was > >> : > dirty hack too. If for "didn't fit" you > mean missing > >> last > >> : > > > byte of frame then this problem > was solved > >> to. > >> : > Bug was in AR71XX SPI code: falling > >> : > > > edge was not provided for last > byte in > >> transfer > >> : > in time and RTC chip acts of falling edge. > >> : > > > Fix was committed before driver. > >> : > > > > >> : > > > > >> : > > > > >> : > > > >> : > > code looks similar, can't tell much > about > >> result as > >> : > kernel hangs for a > >> : > > while before getting this: > >> : > > > >> : > > >> > <<<<<<<<<<<<<<<<<<<<<<<<<<< > >> : > schnipp > >> : > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >> : > > Trap cause = 2 (TLB miss (load or > instr. fetch) > >> - > >> : > kernel mode) > >> : > > [thread pid 4 tid 100009 ] > >> : > > Stopped at > >> : > _thread_lock_flags+0x150: > >> : > lw > v0,60(a3) > >> : > > db> bt > >> : > > Tracing pid 4 tid 100009 td > 0xc0c47270 > >> : > > db_trace_thread+30 (?,?,?,?) ra > 800a6c10 sz 24 > >> : > > 800a6af4+11c (0,?,ffffffff,?) ra > 800a6604 sz > >> 32 > >> : > > 800a6270+394 (?,?,?,?) ra 800a6794 sz > 168 > >> : > > db_command_loop+78 (?,?,?,?) ra > 800a8e68 sz 24 > >> : > > 800a8d60+108 (?,?,?,?) ra 80215ff8 sz > 424 > >> : > > kdb_trap+f8 (?,?,?,?) ra 80474350 sz > 32 > >> : > > trap+134c (?,?,?,?) ra 8046b7fc sz > 176 > >> : > > MipsKernGenException+100 > >> (b,173,804d5de8,deadc0d8) ra > >> : > 801c593c sz 200 > >> : > > _thread_lock_flags+130 (?,?,?,?) ra > 80221f18 sz > >> 56 > >> : > > sleepq_broadcast+ac (?,?,?,?) ra > 801e5f20 sz > >> 40 > >> : > > wakeup+2c (?,?,?,?) ra 8016de18 sz 32 > >> : > > g_io_deliver+198 (?,?,?,?) ra 8016bbd4 > sz 80 > >> : > > 8016b590+644 (?,?,?,?) ra 8016e184 sz > 104 > >> : > > g_io_schedule_down+2ec (?,?,?,?) ra > 8016eb94 sz > >> 64 > >> : > > 8016eb18+7c (?,?,?,?) ra 801a331c sz > 24 > >> : > > fork_exit+a0 (?,?,?,?) ra 80478f10 sz > 48 > >> : > > fork_trampoline+10 (?,?,?,?) ra 0 sz > 0 > >> : > > pid 4 > >> : > > > >> : > > >> > <<<<<<<<<<<<<<<<<<<<<<<<<<< > >> : > schnapp > >> : > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >> : > > > >> : > > will use AR71XX as config file > tomorrow, mine > >> has many > >> : > additional devs > >> : > > configured for booting from usb > devices. > >> : > > > >> : > [...] > >> : > > >> : > seems to make no difference. removed all > mini pci > >> : > devs and most code > >> : > changes. kernel hangs during bootup for a > while. > >> then gets > >> : > a trap. > >> : > > >> : > Source Info: > >> : > > >> : > -------------------------- schnipp > >> : > -------------------------- > >> : > brain:head> svn info > >> : > Path: . > >> : > URL: svn://svn.freebsd.org/base/head > >> : > Repository Root: > svn://svn.freebsd.org/base > >> : > Repository UUID: > >> ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f > >> : > Revision: 202904 > >> : > Node Kind: directory > >> : > Schedule: normal > >> : > Last Changed Author: marcel > >> : > Last Changed Rev: 202904 > >> : > Last Changed Date: 2010-01-24 00:16:50 > +0100 (Sun, > >> 24 Jan > >> : > 2010) > >> : > -------------------------- schnapp > >> : > -------------------------- > >> : > > >> : > -------------------------- schnipp > >> : > -------------------------- > >> : > brain:head> svn stat > >> : > ? GRTAGS > >> : > ? GSYMS > >> : > ? GTAGS > >> : > ? GPATH > >> : > M > sys/kern/vfs_mount.c > >> : > M > sys/mips/conf/AR71XX > >> : > ? > sys/dev/pfc2123 > >> : > -------------------------- schnapp > >> : > -------------------------- > >> : > > >> : > - vfs_mount should be far away. > >> : > - sys/dev/pfc2123 is no longer used. > >> : > - sys/mips/conf/AR71XX altered to include > >> pfc2123_rtc > >> : > > >> : > > >> : > -------------------------- schnipp > >> : > -------------------------- > >> : > FreeBSD 9.0-CURRENT #1: Sun Jan 24 15:58:37 > UTC > >> 2010 > >> : > > >> : > root@pinky.lan.terror.local:/home/smeagle/obj/mips/mips/home/ > > >> smeagle/src/freebsd/head/sys/AR71XX > >> : > mips > >> : > real memory = 134217728 (131072K > bytes) > >> : > avail memory = 125689856 (119MB) > >> : > nexus0: > >> : > clock0: on > nexus0 > >> : > clock0: [FILTER] > >> : > apb0 at irq 4 on nexus0 > >> : > apb0: [FILTER] > >> : > uart0: <16550 or compatible> on apb0 > >> : > uart0: [FILTER] > >> : > uart0: console (115200,n,8,1) > >> : > pcib0 at irq 0 on nexus0 > >> : > pcib0: [FILTER] > >> : > pci0: on pcib0 > >> : > pci0: > at device > >> 0.0 (no > >> : > driver attached) > >> : > pci0: at device 17.0 (no > driver > >> : > attached) > >> : > arge0: ethernet > >> interface> > >> : > at mem > >> : > 0x19000000-0x19000fff irq 2 on nexus0 > >> : > miibus0: on arge0 > >> : > ukphy0: interface> > >> PHY 4 > >> : > on miibus0 > >> : > ukphy0: 10baseT, 10baseT-FDX, > 100baseTX, > >> : > 100baseTX-FDX, 1000baseT-FDX, > >> : > auto > >> : > arge0: Ethernet address: 00:00:00:00:46:61 > >> : > arge0: [FILTER+ITHREAD] > >> : > arge1: ethernet > >> interface> > >> : > at mem > >> : > 0x1a000000-0x1a000fff irq 3 on nexus0 > >> : > arge1: Ethernet address: 00:00:00:00:46:62 > >> : > arge1: [FILTER+ITHREAD] > >> : > spi0: at mem > >> 0x1f000000-0x1f00000f on > >> : > nexus0 > >> : > spibus0: on spi0 > >> : > mx25l0: at cs 0 > on > >> spibus0 > >> : > mx25l0: mx25ll128, sector 65536 bytes, 256 > sectors > >> : > ar71xx_wdog0: timer> > >> on > >> : > nexus0 > >> : > Timecounter "MIPS32" frequency 360000000 Hz > quality > >> 800 > >> : > Timecounters tick every 1.000 msec > >> : > bootpc_init: wired to interface 'arge0' > >> : > Sending DHCP Discover packet from interface > arge0 > >> : > (00:00:00:00:46:61) > >> : > arge0: link state changed to DOWN > >> : > Trap cause = 2 (TLB miss (load or instr. > fetch) - > >> kernel > >> : > mode) > >> : > [thread pid 4 tid 100008 ] > >> : > Stopped at > >> : > _thread_lock_flags+0x150: > >> : > lw > v0,60(a3) > >> : > db> bt > >> : > Tracing pid 4 tid 100008 td 0xc0c414e0 > >> : > db_trace_thread+30 (?,?,?,?) ra 80055900 sz > 24 > >> : > 800557e4+11c (0,?,ffffffff,?) ra 800552f4 > sz 32 > >> : > 80054f60+394 (?,?,?,?) ra 80055484 sz 168 > >> : > db_command_loop+78 (?,?,?,?) ra 80057b58 sz > 24 > >> : > 80057a50+108 (?,?,?,?) ra 8017b7d8 sz 424 > >> : > kdb_trap+f8 (?,?,?,?) ra 8035ab40 sz 32 > >> : > trap+134c (?,?,?,?) ra 80351fec sz 176 > >> : > MipsKernGenException+100 > (b,173,8039ce74,deadc0d8) > >> ra > >> : > 8012c92c sz 200 > >> : > _thread_lock_flags+130 (?,?,?,?) ra > 801876f8 sz 56 > >> : > sleepq_broadcast+ac (?,?,?,?) ra 8014b700 > sz 40 > >> : > wakeup+2c (?,?,?,?) ra 800d6ba8 sz 32 > >> : > g_io_deliver+198 (?,?,?,?) ra 800d4964 sz > 80 > >> : > 800d4320+644 (?,?,?,?) ra 800d6f14 sz 104 > >> : > g_io_schedule_down+2ec (?,?,?,?) ra > 800d7924 sz 64 > >> : > 800d78a8+7c (?,?,?,?) ra 8010c0ac sz 24 > >> : > fork_exit+a0 (?,?,?,?) ra 8035f700 sz 48 > >> : > fork_trampoline+10 (?,?,?,?) ra 0 sz 0 > >> : > pid 4 > >> : > -------------------------- schnapp > >> : > -------------------------- > >> : > > >> : > > >> : > > >> : > > >> : > Flo > >> : > > >> : > > _______________________________________________ > >> : > freebsd-mips@freebsd.org > >> : > mailing list > >> : > http://lists.freebsd.org/mailman/listinfo/freebsd-mips > >> : > To unsubscribe, send any mail to "freebsd-mips-unsubscribe@freebsd.org > > >> " > >> : > > >> : > >> : > >> : > >> : _______________________________________________ > >> : freebsd-mips@freebsd.org > >> mailing list > >> : http://lists.freebsd.org/mailman/listinfo/freebsd-mips > >> : To unsubscribe, send any mail to "freebsd-mips-unsubscribe@freebsd.org > > >> " > >> : > >> : > >> > > > > > > > > _______________________________________________ > > freebsd-mips@freebsd.org > mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-mips > > To unsubscribe, send any mail to "freebsd-mips- > > unsubscribe@freebsd.org" > > > > ------------------------------ > Randall Stewart > 803-317-4952 (cell) > 803-345-0391(direct) > > From owner-freebsd-mips@FreeBSD.ORG Mon Jan 25 23:31:27 2010 Return-Path: Delivered-To: freebsd-mips@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B7E9F106568D for ; Mon, 25 Jan 2010 23:31:27 +0000 (UTC) (envelope-from smeagle@bsdler.de) Received: from hell.bsdler.de (hell-fe0.v6.bsdler.de [IPv6:2001:780:0:19::1]) by mx1.freebsd.org (Postfix) with ESMTP id F085F8FC1C for ; Mon, 25 Jan 2010 23:31:26 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by hell.bsdler.de (Postfix) with ESMTP id 8DAC1B874; Tue, 26 Jan 2010 00:31:24 +0100 (CET) X-Virus-Scanned: amavisd-new at bsdler.de Received: from hell.bsdler.de ([127.0.0.1]) by localhost (hell.bsdler.de [127.0.0.1]) (amavisd-new, port 10024) with LMTP id QOXg9dy33kMd; Tue, 26 Jan 2010 00:31:19 +0100 (CET) Received: from kiste.lan.terror.local (p4FF0A4A4.dip.t-dialin.net [79.240.164.164]) by hell.bsdler.de (Postfix) with ESMTPSA id 45303B873; Tue, 26 Jan 2010 00:31:19 +0100 (CET) Received: from [172.17.21.80] (brain.lan.terror.local [172.17.21.80]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by kiste.lan.terror.local (Postfix) with ESMTPS id DE8624AE07; Tue, 26 Jan 2010 01:01:42 +0100 (CET) From: Florian Kruegl To: Neelkanth Natu In-Reply-To: <434364.57659.qm@web34405.mail.mud.yahoo.com> References: <434364.57659.qm@web34405.mail.mud.yahoo.com> Content-Type: text/plain; charset="us-ascii" Date: Tue, 26 Jan 2010 00:28:55 +0100 Message-ID: <1264462135.2647.104.camel@brain.lan.terror.local> Mime-Version: 1.0 X-Mailer: Evolution 2.28.2 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-mips@freebsd.org Subject: Re: AR71XX RTC X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: smeagle@bsdler.de List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jan 2010 23:31:27 -0000 Hi On Mon, 2010-01-25 at 01:30 -0800, Neelkanth Natu wrote: > Hi Flo, > > Can you try the following patch and see if it helps with the > hang-followed-by-trap problem? > > I am seeing a similar problem on the Sibyte and this patch gets me > past it. > > best > Neel > > Index: swtch.S > =================================================================== > --- swtch.S (revision 202961) > +++ swtch.S (working copy) > @@ -323,7 +323,7 @@ > * to be saved with the other registers do so here. > */ > > - sw a3, TD_LOCK(a0) # Switchout td_lock > + sw a2, TD_LOCK(a3) # Switchout td_lock > > mips_sw1: > #if defined(SMP) && defined(SCHED_ULE) > > sorry for the delay, updated to head 202988, change was already commited, trap is gone :-) rtc is detected and complains about: =================================================================== Invalid time in real time clock. Check and reset the date immediately! =================================================================== Regards Flo > --- On Sun, 1/24/10, Florian Kruegl wrote: > > > From: Florian Kruegl > > Subject: Re: AR71XX RTC > > To: "Oleksandr Tymoshenko" > > Cc: freebsd-mips@freebsd.org > > Date: Sunday, January 24, 2010, 8:52 AM > > Hi, > > > > On Sun, 2010-01-24 at 02:41 +0100, Florian Kruegl wrote: > > > On Sat, 2010-01-23 at 16:53 -0800, Oleksandr > > Tymoshenko wrote: > > > > On 2010-01-23, at 4:44 PM, Florian Kruegl wrote: > > > > > > > > > Hi, > > > > > > > > > > On Sat, 2010-01-23 at 16:21 -0800, Oleksandr > > Tymoshenko wrote: > > > > >> On 2010-01-23, at 4:00 PM, Florian > > Kruegl wrote: > > > > >> > > > > >>> Hi, > > > > >>> > > > > >>> anyone working on pfc2123 driver for > > RouterStation Pro? > > > > >>> Seems quite well documented, one > > issue might be CS hack, but the rest > > > > >>> should be straight. > > > > >> Driver was commited > > yesterday: > > > > >> http://svn.freebsd.org/viewvc/base?view=revision&revision=202839 > > > > >> > > > > >> And yes, CS hack is the problem. I'm > > trying to figure out how to fit it into FreeBSD > > > > >> SPI framework. > > > > > > > > > > sounds good, will do an update as soon as i > > removed me work from code. > > > > > My CS "solution" was more than crude, but > > the frames simply didn't > > > > > fit... so I am looking forward for a > > different one :) > > > > > > > > Yeah, my CS solution was > > dirty hack too. If for "didn't fit" you mean missing last > > > > byte of frame then this problem was solved to. > > Bug was in AR71XX SPI code: falling > > > > edge was not provided for last byte in transfer > > in time and RTC chip acts of falling edge. > > > > Fix was committed before driver. > > > > > > > > > > > > > > > > > > code looks similar, can't tell much about result as > > kernel hangs for a > > > while before getting this: > > > > > <<<<<<<<<<<<<<<<<<<<<<<<<<< > > schnipp > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > > > Trap cause = 2 (TLB miss (load or instr. fetch) - > > kernel mode) > > > [thread pid 4 tid 100009 ] > > > Stopped at > > _thread_lock_flags+0x150: > > lw v0,60(a3) > > > db> bt > > > Tracing pid 4 tid 100009 td 0xc0c47270 > > > db_trace_thread+30 (?,?,?,?) ra 800a6c10 sz 24 > > > 800a6af4+11c (0,?,ffffffff,?) ra 800a6604 sz 32 > > > 800a6270+394 (?,?,?,?) ra 800a6794 sz 168 > > > db_command_loop+78 (?,?,?,?) ra 800a8e68 sz 24 > > > 800a8d60+108 (?,?,?,?) ra 80215ff8 sz 424 > > > kdb_trap+f8 (?,?,?,?) ra 80474350 sz 32 > > > trap+134c (?,?,?,?) ra 8046b7fc sz 176 > > > MipsKernGenException+100 (b,173,804d5de8,deadc0d8) ra > > 801c593c sz 200 > > > _thread_lock_flags+130 (?,?,?,?) ra 80221f18 sz 56 > > > sleepq_broadcast+ac (?,?,?,?) ra 801e5f20 sz 40 > > > wakeup+2c (?,?,?,?) ra 8016de18 sz 32 > > > g_io_deliver+198 (?,?,?,?) ra 8016bbd4 sz 80 > > > 8016b590+644 (?,?,?,?) ra 8016e184 sz 104 > > > g_io_schedule_down+2ec (?,?,?,?) ra 8016eb94 sz 64 > > > 8016eb18+7c (?,?,?,?) ra 801a331c sz 24 > > > fork_exit+a0 (?,?,?,?) ra 80478f10 sz 48 > > > fork_trampoline+10 (?,?,?,?) ra 0 sz 0 > > > pid 4 > > > > > <<<<<<<<<<<<<<<<<<<<<<<<<<< > > schnapp > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > > > > > > will use AR71XX as config file tomorrow, mine has many > > additional devs > > > configured for booting from usb devices. > > > > > [...] > > > > seems to make no difference. removed all mini pci > > devs and most code > > changes. kernel hangs during bootup for a while. then gets > > a trap. > > > > Source Info: > > > > -------------------------- schnipp > > -------------------------- > > brain:head> svn info > > Path: . > > URL: svn://svn.freebsd.org/base/head > > Repository Root: svn://svn.freebsd.org/base > > Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f > > Revision: 202904 > > Node Kind: directory > > Schedule: normal > > Last Changed Author: marcel > > Last Changed Rev: 202904 > > Last Changed Date: 2010-01-24 00:16:50 +0100 (Sun, 24 Jan > > 2010) > > -------------------------- schnapp > > -------------------------- > > > > -------------------------- schnipp > > -------------------------- > > brain:head> svn stat > > ? GRTAGS > > ? GSYMS > > ? GTAGS > > ? GPATH > > M sys/kern/vfs_mount.c > > M sys/mips/conf/AR71XX > > ? sys/dev/pfc2123 > > -------------------------- schnapp > > -------------------------- > > > > - vfs_mount should be far away. > > - sys/dev/pfc2123 is no longer used. > > - sys/mips/conf/AR71XX altered to include pfc2123_rtc > > > > > > -------------------------- schnipp > > -------------------------- > > FreeBSD 9.0-CURRENT #1: Sun Jan 24 15:58:37 UTC 2010 > > > > root@pinky.lan.terror.local:/home/smeagle/obj/mips/mips/home/smeagle/src/freebsd/head/sys/AR71XX > > mips > > real memory = 134217728 (131072K bytes) > > avail memory = 125689856 (119MB) > > nexus0: > > clock0: on nexus0 > > clock0: [FILTER] > > apb0 at irq 4 on nexus0 > > apb0: [FILTER] > > uart0: <16550 or compatible> on apb0 > > uart0: [FILTER] > > uart0: console (115200,n,8,1) > > pcib0 at irq 0 on nexus0 > > pcib0: [FILTER] > > pci0: on pcib0 > > pci0: at device 0.0 (no > > driver attached) > > pci0: at device 17.0 (no driver > > attached) > > arge0: > > at mem > > 0x19000000-0x19000fff irq 2 on nexus0 > > miibus0: on arge0 > > ukphy0: PHY 4 > > on miibus0 > > ukphy0: 10baseT, 10baseT-FDX, 100baseTX, > > 100baseTX-FDX, 1000baseT-FDX, > > auto > > arge0: Ethernet address: 00:00:00:00:46:61 > > arge0: [FILTER+ITHREAD] > > arge1: > > at mem > > 0x1a000000-0x1a000fff irq 3 on nexus0 > > arge1: Ethernet address: 00:00:00:00:46:62 > > arge1: [FILTER+ITHREAD] > > spi0: at mem 0x1f000000-0x1f00000f on > > nexus0 > > spibus0: on spi0 > > mx25l0: at cs 0 on spibus0 > > mx25l0: mx25ll128, sector 65536 bytes, 256 sectors > > ar71xx_wdog0: on > > nexus0 > > Timecounter "MIPS32" frequency 360000000 Hz quality 800 > > Timecounters tick every 1.000 msec > > bootpc_init: wired to interface 'arge0' > > Sending DHCP Discover packet from interface arge0 > > (00:00:00:00:46:61) > > arge0: link state changed to DOWN > > Trap cause = 2 (TLB miss (load or instr. fetch) - kernel > > mode) > > [thread pid 4 tid 100008 ] > > Stopped at > > _thread_lock_flags+0x150: > > lw v0,60(a3) > > db> bt > > Tracing pid 4 tid 100008 td 0xc0c414e0 > > db_trace_thread+30 (?,?,?,?) ra 80055900 sz 24 > > 800557e4+11c (0,?,ffffffff,?) ra 800552f4 sz 32 > > 80054f60+394 (?,?,?,?) ra 80055484 sz 168 > > db_command_loop+78 (?,?,?,?) ra 80057b58 sz 24 > > 80057a50+108 (?,?,?,?) ra 8017b7d8 sz 424 > > kdb_trap+f8 (?,?,?,?) ra 8035ab40 sz 32 > > trap+134c (?,?,?,?) ra 80351fec sz 176 > > MipsKernGenException+100 (b,173,8039ce74,deadc0d8) ra > > 8012c92c sz 200 > > _thread_lock_flags+130 (?,?,?,?) ra 801876f8 sz 56 > > sleepq_broadcast+ac (?,?,?,?) ra 8014b700 sz 40 > > wakeup+2c (?,?,?,?) ra 800d6ba8 sz 32 > > g_io_deliver+198 (?,?,?,?) ra 800d4964 sz 80 > > 800d4320+644 (?,?,?,?) ra 800d6f14 sz 104 > > g_io_schedule_down+2ec (?,?,?,?) ra 800d7924 sz 64 > > 800d78a8+7c (?,?,?,?) ra 8010c0ac sz 24 > > fork_exit+a0 (?,?,?,?) ra 8035f700 sz 48 > > fork_trampoline+10 (?,?,?,?) ra 0 sz 0 > > pid 4 > > -------------------------- schnapp > > -------------------------- > > > > > > > > > > Flo > > > > _______________________________________________ > > freebsd-mips@freebsd.org > > mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-mips > > To unsubscribe, send any mail to "freebsd-mips-unsubscribe@freebsd.org" > > > > > > From owner-freebsd-mips@FreeBSD.ORG Mon Jan 25 23:53:29 2010 Return-Path: Delivered-To: freebsd-mips@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ACAAB106568D; Mon, 25 Jan 2010 23:53:29 +0000 (UTC) (envelope-from rrs@lakerest.net) Received: from lakerest.net (unknown [IPv6:2001:240:585:2:213:d4ff:fef3:2d8d]) by mx1.freebsd.org (Postfix) with ESMTP id 18C0F8FC1F; Mon, 25 Jan 2010 23:53:28 +0000 (UTC) Received: from mobile-166-129-165-043.mycingular.net (mobile-166-129-165-043.mycingular.net [166.129.165.43] (may be forged)) (authenticated bits=0) by lakerest.net (8.14.3/8.14.3) with ESMTP id o0PNr5SJ006866 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 25 Jan 2010 18:53:13 -0500 (EST) (envelope-from rrs@lakerest.net) Message-Id: <74D48EE5-544E-44D4-9644-2349E9AA9796@lakerest.net> From: Randall Stewart To: Neelkanth Natu In-Reply-To: <489828.45501.qm@web34403.mail.mud.yahoo.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 25 Jan 2010 15:52:59 -0800 References: <489828.45501.qm@web34403.mail.mud.yahoo.com> X-Mailer: Apple Mail (2.936) Cc: attilio@freebsd.org, freebsd-mips@freebsd.org Subject: Re: AR71XX RTC X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jan 2010 23:53:29 -0000 Neel: Thanks that makes a LOT of sense.. So basically the mtx passed is NOT what is currently in td_lock and we want it updated as we switch. Cool.. then that makes the code look much clearer Thanks R On Jan 25, 2010, at 1:51 PM, Neelkanth Natu wrote: > Hi Randall, > > --- On Mon, 1/25/10, Randall Stewart wrote: > >> From: Randall Stewart >> Subject: Re: AR71XX RTC >> To: "Neelkanth Natu" >> Cc: "M. Warner Losh" , freebsd-mips@freebsd.org >> Date: Monday, January 25, 2010, 12:51 PM >> Neil: >> >> Thanks for the patch.. it does look good since the old >> code was tromping part of the old threads PCB which is >> definitely not right ;-0 .. I do have a question for you.. >> forgive my ignorance.. >> >> What exactly are we trying to switch here. It seems >> that cpu_switch(...) is now being called with >> oldtd, newtd and mtx... >> >> I see that the thread structure has a struct mutex *td_lock >> as >> its first member. But what is this supposed to be pointing >> to? >> And when we switch are we trying to take the >> >> oldtd->td_lock and place it into the newtd->td_lock >> >> Or? >> >> What... I guess I just don't have any context for whats >> going on.. >> > > I am not very sure about this myself so take this with a grain of > salt: > > When a thread is being switched out because it is on a sleep queue the > intent is that some other thread running on a different cpu should > not be > allowed to muck with this thread's state. To make this happen the > 'td_lock' > of 'oldtd' is switched from what it was originally (viz. the sleep > queue > chain lock) to 'blocked_lock'. The 'blocked_lock' is special because > it is always locked. This all happens in sched_switch(). > > cpu_switch() is passed the original value of 'oldtd->td_lock' > as the third argument. When the context is switched to 'newtd' we will > switch back the 'oldtd->td_lock' from 'blocked_lock' to its original > value. And this way we don't lose any wakeups that may happen while we > are in sched_switch(). > > At least that is my very naive understanding of it. CCing Attilio to > shed more light on this. > > best > Neel > >> R >> >> >> >> On Jan 25, 2010, at 12:41 PM, Neelkanth Natu wrote: >> >>> Hi Warner, >>> >>> The patch looks good. Please commit it. >>> >>> The reason we started seeing this recently is because >> of this: >>> http://svn.freebsd.org/viewvc/base/head/sys/kern/sched_4bsd.c?r1=202889&r2=202888&pathrev=202889 >>> >>> In particular the call to thread_block_lock() will >> point 'td_lock' to >>> 'blocked_lock' and if we don't switch it back in >> cpu_switch() then >>> anybody trying to call thread_lock() on the thread >> will panic. >>> >>> best >>> Neel >>> >>> --- On Mon, 1/25/10, M. Warner Losh >> wrote: >>> >>>> From: M. Warner Losh >>>> Subject: Re: AR71XX RTC >>>> To: neelnatu@yahoo.com >>>> Cc: gonzo@bluezbox.com, >> smeagle@bsdler.de, >> freebsd-mips@FreeBSD.org >>>> Date: Monday, January 25, 2010, 8:31 AM >>>> In message: <434364.57659.qm@web34405.mail.mud.yahoo.com> >>>> Neelkanth >> Natu >>>> >>>> writes: >>>> : Hi Flo, >>>> : >>>> : Can you try the following patch and see if it >> helps with >>>> the >>>> : hang-followed-by-trap problem? >>>> : >>>> : I am seeing a similar problem on the Sibyte and >> this >>>> patch gets me >>>> : past it. >>>> : >>>> : best >>>> : Neel >>>> : >>>> : Index: swtch.S >>>> : >>>> >> =================================================================== >>>> : --- swtch.S (revision 202961) >>>> : +++ swtch.S (working copy) >>>> : @@ -323,7 +323,7 @@ >>>> : * to be saved >> with >>>> the other registers do so here. >>>> : */ >>>> : >>>> : - sw a3, >>>> TD_LOCK(a0) >>>> # Switchout td_lock >>>> : + sw a2, >>>> TD_LOCK(a3) >>>> # Switchout td_lock >>>> : >>>> : mips_sw1: >>>> : #if defined(SMP) && >> defined(SCHED_ULE) >>>> >>>> I really like this patch. For the OCTEON I >> went from >>>> having all kinds >>>> of head-scratcher problems on boot that I was >> about to look >>>> at >>>> instruction traces in the simulator to try to >> track down to >>>> an >>>> immediate mountroot> prompt. So after >> reading the >>>> code, my first >>>> reaction is "how the heck did the old code work as >> well as >>>> it did?" >>>> and my second reaction is "This is obviously the >> right fix >>>> since a3 is >>>> a saved copy of a0, and a0 points to the pcb at >> this point, >>>> not the >>>> old thread." >>>> >>>> I've touched up the comments a bit. Maybe >> the >>>> register assignments is >>>> a bit of overkill, but this is a complicated >> function >>>> that's very >>>> tricky. What do you think of this patch: >>>> >>>> Index: sys/mips/mips/swtch.S >>>> >> =================================================================== >>>> --- sys/mips/mips/swtch.S (revision >>>> 202867) >>>> +++ sys/mips/mips/swtch.S (working >> copy) >>>> @@ -282,9 +282,10 @@ >>>> END(mips_cpu_throw) >>>> >>>> /* >>>> - *XXX Fixme: should be written to >> new >>>> interface that requires lock >>>> - * storage. We >>>> fake it for now. >>>> - * cpu_switch(struct thread *old, struct thread >> *new); >>>> + * cpu_switch(struct thread *old, struct thread >> *new, >>>> struct mutex *mtx); >>>> + * a0 - old >>>> + * a1 - new >>>> + * a2 - mtx >>>> * Find the highest priority process and >> resume it. >>>> */ >>>> NON_LEAF(cpu_switch, STAND_FRAME_SIZE, ra) >>>> @@ -323,7 +324,7 @@ >>>> * to be saved with the other >>>> registers do so here. >>>> */ >>>> >>>> - sw a3, >>>> TD_LOCK(a0) >>>> # Switchout td_lock >>>> + sw a2, >>>> TD_LOCK(a3) >>>> # Switchout td_lock >>>> >>>> mips_sw1: >>>> #if defined(SMP) && defined(SCHED_ULE) >>>> >>>> >>>> Thanks for saving me hours of debugging. :) >>>> >>>> Warner >>>> >>>> >>>> : --- On Sun, 1/24/10, Florian Kruegl >>>> wrote: >>>> : >>>> : > From: Florian Kruegl >>>> : > Subject: Re: AR71XX RTC >>>> : > To: "Oleksandr Tymoshenko" >>>> : > Cc: freebsd-mips@freebsd.org >>>> : > Date: Sunday, January 24, 2010, 8:52 AM >>>> : > Hi, >>>> : > >>>> : > On Sun, 2010-01-24 at 02:41 +0100, Florian >> Kruegl >>>> wrote: >>>> : > > On Sat, 2010-01-23 at 16:53 -0800, >> Oleksandr >>>> : > Tymoshenko wrote: >>>> : > > > On 2010-01-23, at 4:44 PM, >> Florian Kruegl >>>> wrote: >>>> : > > > >>>> : > > > > Hi, >>>> : > > > > >>>> : > > > > On Sat, 2010-01-23 at 16:21 >> -0800, >>>> Oleksandr >>>> : > Tymoshenko wrote: >>>> : > > > >> On 2010-01-23, at 4:00 >> PM, >>>> Florian >>>> : > Kruegl wrote: >>>> : > > > >> >>>> : > > > >>> Hi, >>>> : > > > >>> >>>> : > > > >>> anyone working on >> pfc2123 >>>> driver for >>>> : > RouterStation Pro? >>>> : > > > >>> Seems quite well >> documented, >>>> one >>>> : > issue might be CS hack, but the rest >>>> : > > > >>> should be straight. >>>> : > > > >> Driver was >> commited >>>> : > yesterday: >>>> : > > > >> http://svn.freebsd.org/viewvc/base?view=revision&revision=202839 >>>> : > > > >> >>>> : > > > >> And yes, CS hack is the >> problem. >>>> I'm >>>> : > trying to figure out how to fit it into >> FreeBSD >>>> : > > > >> SPI framework. >>>> : > > > > >>>> : > > > > sounds good, will do an >> update as >>>> soon as i >>>> : > removed me work from code. >>>> : > > > > My CS "solution" was more >> than crude, >>>> but >>>> : > the frames simply didn't >>>> : > > > > fit... so I am looking >> forward for a >>>> : > different one :) >>>> : > > > >>>> : > > > Yeah, my >> CS solution was >>>> : > dirty hack too. If for "didn't fit" you >> mean missing >>>> last >>>> : > > > byte of frame then this problem >> was solved >>>> to. >>>> : > Bug was in AR71XX SPI code: falling >>>> : > > > edge was not provided for last >> byte in >>>> transfer >>>> : > in time and RTC chip acts of falling edge. >>>> : > > > Fix was committed before driver. >>>> : > > > >>>> : > > > >>>> : > > > >>>> : > > >>>> : > > code looks similar, can't tell much >> about >>>> result as >>>> : > kernel hangs for a >>>> : > > while before getting this: >>>> : > > >>>> : > >>>> >> <<<<<<<<<<<<<<<<<<<<<<<<<<< >>>> : > schnipp >>>> : > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>> : > > Trap cause = 2 (TLB miss (load or >> instr. fetch) >>>> - >>>> : > kernel mode) >>>> : > > [thread pid 4 tid 100009 ] >>>> : > > Stopped at >>>> : > _thread_lock_flags+0x150: >>>> : > lw >> v0,60(a3) >>>> : > > db> bt >>>> : > > Tracing pid 4 tid 100009 td >> 0xc0c47270 >>>> : > > db_trace_thread+30 (?,?,?,?) ra >> 800a6c10 sz 24 >>>> : > > 800a6af4+11c (0,?,ffffffff,?) ra >> 800a6604 sz >>>> 32 >>>> : > > 800a6270+394 (?,?,?,?) ra 800a6794 sz >> 168 >>>> : > > db_command_loop+78 (?,?,?,?) ra >> 800a8e68 sz 24 >>>> : > > 800a8d60+108 (?,?,?,?) ra 80215ff8 sz >> 424 >>>> : > > kdb_trap+f8 (?,?,?,?) ra 80474350 sz >> 32 >>>> : > > trap+134c (?,?,?,?) ra 8046b7fc sz >> 176 >>>> : > > MipsKernGenException+100 >>>> (b,173,804d5de8,deadc0d8) ra >>>> : > 801c593c sz 200 >>>> : > > _thread_lock_flags+130 (?,?,?,?) ra >> 80221f18 sz >>>> 56 >>>> : > > sleepq_broadcast+ac (?,?,?,?) ra >> 801e5f20 sz >>>> 40 >>>> : > > wakeup+2c (?,?,?,?) ra 8016de18 sz 32 >>>> : > > g_io_deliver+198 (?,?,?,?) ra 8016bbd4 >> sz 80 >>>> : > > 8016b590+644 (?,?,?,?) ra 8016e184 sz >> 104 >>>> : > > g_io_schedule_down+2ec (?,?,?,?) ra >> 8016eb94 sz >>>> 64 >>>> : > > 8016eb18+7c (?,?,?,?) ra 801a331c sz >> 24 >>>> : > > fork_exit+a0 (?,?,?,?) ra 80478f10 sz >> 48 >>>> : > > fork_trampoline+10 (?,?,?,?) ra 0 sz >> 0 >>>> : > > pid 4 >>>> : > > >>>> : > >>>> >> <<<<<<<<<<<<<<<<<<<<<<<<<<< >>>> : > schnapp >>>> : > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>> : > > >>>> : > > will use AR71XX as config file >> tomorrow, mine >>>> has many >>>> : > additional devs >>>> : > > configured for booting from usb >> devices. >>>> : > > >>>> : > [...] >>>> : > >>>> : > seems to make no difference. removed all >> mini pci >>>> : > devs and most code >>>> : > changes. kernel hangs during bootup for a >> while. >>>> then gets >>>> : > a trap. >>>> : > >>>> : > Source Info: >>>> : > >>>> : > -------------------------- schnipp >>>> : > -------------------------- >>>> : > brain:head> svn info >>>> : > Path: . >>>> : > URL: svn://svn.freebsd.org/base/head >>>> : > Repository Root: >> svn://svn.freebsd.org/base >>>> : > Repository UUID: >>>> ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f >>>> : > Revision: 202904 >>>> : > Node Kind: directory >>>> : > Schedule: normal >>>> : > Last Changed Author: marcel >>>> : > Last Changed Rev: 202904 >>>> : > Last Changed Date: 2010-01-24 00:16:50 >> +0100 (Sun, >>>> 24 Jan >>>> : > 2010) >>>> : > -------------------------- schnapp >>>> : > -------------------------- >>>> : > >>>> : > -------------------------- schnipp >>>> : > -------------------------- >>>> : > brain:head> svn stat >>>> : > ? GRTAGS >>>> : > ? GSYMS >>>> : > ? GTAGS >>>> : > ? GPATH >>>> : > M >> sys/kern/vfs_mount.c >>>> : > M >> sys/mips/conf/AR71XX >>>> : > ? >> sys/dev/pfc2123 >>>> : > -------------------------- schnapp >>>> : > -------------------------- >>>> : > >>>> : > - vfs_mount should be far away. >>>> : > - sys/dev/pfc2123 is no longer used. >>>> : > - sys/mips/conf/AR71XX altered to include >>>> pfc2123_rtc >>>> : > >>>> : > >>>> : > -------------------------- schnipp >>>> : > -------------------------- >>>> : > FreeBSD 9.0-CURRENT #1: Sun Jan 24 15:58:37 >> UTC >>>> 2010 >>>> : > >>>> : > root@pinky.lan.terror.local:/home/smeagle/obj/mips/mips/home/ >> >>>> smeagle/src/freebsd/head/sys/AR71XX >>>> : > mips >>>> : > real memory = 134217728 (131072K >> bytes) >>>> : > avail memory = 125689856 (119MB) >>>> : > nexus0: >>>> : > clock0: on >> nexus0 >>>> : > clock0: [FILTER] >>>> : > apb0 at irq 4 on nexus0 >>>> : > apb0: [FILTER] >>>> : > uart0: <16550 or compatible> on apb0 >>>> : > uart0: [FILTER] >>>> : > uart0: console (115200,n,8,1) >>>> : > pcib0 at irq 0 on nexus0 >>>> : > pcib0: [FILTER] >>>> : > pci0: on pcib0 >>>> : > pci0: >> at device >>>> 0.0 (no >>>> : > driver attached) >>>> : > pci0: at device 17.0 (no >> driver >>>> : > attached) >>>> : > arge0: > ethernet >>>> interface> >>>> : > at mem >>>> : > 0x19000000-0x19000fff irq 2 on nexus0 >>>> : > miibus0: on arge0 >>>> : > ukphy0: > interface> >>>> PHY 4 >>>> : > on miibus0 >>>> : > ukphy0: 10baseT, 10baseT-FDX, >> 100baseTX, >>>> : > 100baseTX-FDX, 1000baseT-FDX, >>>> : > auto >>>> : > arge0: Ethernet address: 00:00:00:00:46:61 >>>> : > arge0: [FILTER+ITHREAD] >>>> : > arge1: > ethernet >>>> interface> >>>> : > at mem >>>> : > 0x1a000000-0x1a000fff irq 3 on nexus0 >>>> : > arge1: Ethernet address: 00:00:00:00:46:62 >>>> : > arge1: [FILTER+ITHREAD] >>>> : > spi0: at mem >>>> 0x1f000000-0x1f00000f on >>>> : > nexus0 >>>> : > spibus0: on spi0 >>>> : > mx25l0: at cs 0 >> on >>>> spibus0 >>>> : > mx25l0: mx25ll128, sector 65536 bytes, 256 >> sectors >>>> : > ar71xx_wdog0: > timer> >>>> on >>>> : > nexus0 >>>> : > Timecounter "MIPS32" frequency 360000000 Hz >> quality >>>> 800 >>>> : > Timecounters tick every 1.000 msec >>>> : > bootpc_init: wired to interface 'arge0' >>>> : > Sending DHCP Discover packet from interface >> arge0 >>>> : > (00:00:00:00:46:61) >>>> : > arge0: link state changed to DOWN >>>> : > Trap cause = 2 (TLB miss (load or instr. >> fetch) - >>>> kernel >>>> : > mode) >>>> : > [thread pid 4 tid 100008 ] >>>> : > Stopped at >>>> : > _thread_lock_flags+0x150: >>>> : > lw >> v0,60(a3) >>>> : > db> bt >>>> : > Tracing pid 4 tid 100008 td 0xc0c414e0 >>>> : > db_trace_thread+30 (?,?,?,?) ra 80055900 sz >> 24 >>>> : > 800557e4+11c (0,?,ffffffff,?) ra 800552f4 >> sz 32 >>>> : > 80054f60+394 (?,?,?,?) ra 80055484 sz 168 >>>> : > db_command_loop+78 (?,?,?,?) ra 80057b58 sz >> 24 >>>> : > 80057a50+108 (?,?,?,?) ra 8017b7d8 sz 424 >>>> : > kdb_trap+f8 (?,?,?,?) ra 8035ab40 sz 32 >>>> : > trap+134c (?,?,?,?) ra 80351fec sz 176 >>>> : > MipsKernGenException+100 >> (b,173,8039ce74,deadc0d8) >>>> ra >>>> : > 8012c92c sz 200 >>>> : > _thread_lock_flags+130 (?,?,?,?) ra >> 801876f8 sz 56 >>>> : > sleepq_broadcast+ac (?,?,?,?) ra 8014b700 >> sz 40 >>>> : > wakeup+2c (?,?,?,?) ra 800d6ba8 sz 32 >>>> : > g_io_deliver+198 (?,?,?,?) ra 800d4964 sz >> 80 >>>> : > 800d4320+644 (?,?,?,?) ra 800d6f14 sz 104 >>>> : > g_io_schedule_down+2ec (?,?,?,?) ra >> 800d7924 sz 64 >>>> : > 800d78a8+7c (?,?,?,?) ra 8010c0ac sz 24 >>>> : > fork_exit+a0 (?,?,?,?) ra 8035f700 sz 48 >>>> : > fork_trampoline+10 (?,?,?,?) ra 0 sz 0 >>>> : > pid 4 >>>> : > -------------------------- schnapp >>>> : > -------------------------- >>>> : > >>>> : > >>>> : > >>>> : > >>>> : > Flo >>>> : > >>>> : > >> _______________________________________________ >>>> : > freebsd-mips@freebsd.org >>>> : > mailing list >>>> : > http://lists.freebsd.org/mailman/listinfo/freebsd-mips >>>> : > To unsubscribe, send any mail to "freebsd-mips-unsubscribe@freebsd.org >> >>>> " >>>> : > >>>> : >>>> : >>>> : >>>> : _______________________________________________ >>>> : freebsd-mips@freebsd.org >>>> mailing list >>>> : http://lists.freebsd.org/mailman/listinfo/freebsd-mips >>>> : To unsubscribe, send any mail to "freebsd-mips-unsubscribe@freebsd.org >> >>>> " >>>> : >>>> : >>>> >>> >>> >>> >>> _______________________________________________ >>> freebsd-mips@freebsd.org >> mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-mips >>> To unsubscribe, send any mail to "freebsd-mips- >>> unsubscribe@freebsd.org" >>> >> >> ------------------------------ >> Randall Stewart >> 803-317-4952 (cell) >> 803-345-0391(direct) >> >> > > > > ------------------------------ Randall Stewart 803-317-4952 (cell) 803-345-0391(direct) From owner-freebsd-mips@FreeBSD.ORG Tue Jan 26 02:20:27 2010 Return-Path: Delivered-To: freebsd-mips@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 041B9106566B; Tue, 26 Jan 2010 02:20:27 +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 A324F8FC15; Tue, 26 Jan 2010 02:20:26 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.3/8.14.1) with ESMTP id o0Q2JAVk061311; Mon, 25 Jan 2010 19:19:11 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Mon, 25 Jan 2010 19:19:59 -0700 (MST) Message-Id: <20100125.191959.956847443352467531.imp@bsdimp.com> To: rrs@lakerest.net From: "M. Warner Losh" In-Reply-To: <74D48EE5-544E-44D4-9644-2349E9AA9796@lakerest.net> References: <489828.45501.qm@web34403.mail.mud.yahoo.com> <74D48EE5-544E-44D4-9644-2349E9AA9796@lakerest.net> X-Mailer: Mew version 6.3 on Emacs 22.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: attilio@FreeBSD.org, freebsd-mips@FreeBSD.org Subject: Re: AR71XX RTC X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2010 02:20:27 -0000 In message: <74D48EE5-544E-44D4-9644-2349E9AA9796@lakerest.net> Randall Stewart writes: : Thanks that makes a LOT of sense.. So basically the : mtx passed is NOT what is currently in td_lock and we : want it updated as we switch. Yes. I think there still might be a bit of oddness here and there, since the cavium port has a weird access to sysctl issue when a rm_lock is involved. I'm not at all sure why that would be... It may be scheduling related, but it may also just be some minor init the cavium is doing that's just a bit off... Warner From owner-freebsd-mips@FreeBSD.ORG Tue Jan 26 02:48:40 2010 Return-Path: Delivered-To: freebsd-mips@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 13DA3106566B; Tue, 26 Jan 2010 02:48:40 +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 CA8938FC15; Tue, 26 Jan 2010 02:48:39 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.3/8.14.1) with ESMTP id o0Q2fJ7r061568; Mon, 25 Jan 2010 19:41:19 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Mon, 25 Jan 2010 19:42:07 -0700 (MST) Message-Id: <20100125.194207.1000278277145525469.imp@bsdimp.com> To: rrs@lakerest.net From: "M. Warner Losh" In-Reply-To: <20100125.191959.956847443352467531.imp@bsdimp.com> References: <489828.45501.qm@web34403.mail.mud.yahoo.com> <74D48EE5-544E-44D4-9644-2349E9AA9796@lakerest.net> <20100125.191959.956847443352467531.imp@bsdimp.com> X-Mailer: Mew version 6.3 on Emacs 22.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: attilio@FreeBSD.org, freebsd-mips@FreeBSD.org Subject: Re: AR71XX RTC X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2010 02:48:40 -0000 In message: <20100125.191959.956847443352467531.imp@bsdimp.com> "M. Warner Losh" writes: : In message: <74D48EE5-544E-44D4-9644-2349E9AA9796@lakerest.net> : Randall Stewart writes: : : Thanks that makes a LOT of sense.. So basically the : : mtx passed is NOT what is currently in td_lock and we : : want it updated as we switch. : : Yes. : : I think there still might be a bit of oddness here and there, since : the cavium port has a weird access to sysctl issue when a rm_lock is : involved. I'm not at all sure why that would be... It may be : scheduling related, but it may also just be some minor init the cavium : is doing that's just a bit off... Looks like the oddness was due to problems in octeon init code... We're past that now... Warner From owner-freebsd-mips@FreeBSD.ORG Tue Jan 26 06:25:06 2010 Return-Path: Delivered-To: freebsd-mips@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6F5401065670 for ; Tue, 26 Jan 2010 06:25:06 +0000 (UTC) (envelope-from alancyang@gmail.com) Received: from mail-px0-f183.google.com (mail-px0-f183.google.com [209.85.216.183]) by mx1.freebsd.org (Postfix) with ESMTP id 468BB8FC13 for ; Tue, 26 Jan 2010 06:25:06 +0000 (UTC) Received: by pxi13 with SMTP id 13so3004034pxi.3 for ; Mon, 25 Jan 2010 22:25:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=PPyoDXILn1rzhJ+fbn8xgDX/l3Jz0bslmf/3xeKJv3Q=; b=LvRpXCN01WhIhqH2aNjLLvnPhOl2v6Le5ZnxkNwH0Km+Pq6VnnBCXW+O7zhdl/M6E3 GrUsJM0pjTYV/3dNpwz4YsA/kRErOSDrq8fCoG8JIFaf3MGZiZwV9TqVX1LcxRsUBzz3 L2OxL/uCVoKXYkd8t4W8kAAdeb2FKY74NmDco= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=wiMHWub1liq9opnkxV353Cd4H/3EqBDV0W+Dgm/HIVzh0dRdImR8fMnoxQhB3m/nuY VXgyzM2fPfTyVgsB5lURJ1lRZkfJlRcEpgClmhoDiKD6x8+XROI2xnnR0Q2zXdAlYrMU CVpwjo5GMiTwS8Ff6hP8jeHX6lsixlrQCl42E= MIME-Version: 1.0 Received: by 10.114.98.12 with SMTP id v12mr5263066wab.146.1264487104777; Mon, 25 Jan 2010 22:25:04 -0800 (PST) In-Reply-To: <20100121.163312.886429907199307448.imp@bsdimp.com> References: <290865fd1001051526i73dd96d7x18a7a842b903b61d@mail.gmail.com> <4B4433ED.10103@mahan.org> <290865fd1001211445n1b469e11o2f37598c989dbaf7@mail.gmail.com> <20100121.163312.886429907199307448.imp@bsdimp.com> Date: Mon, 25 Jan 2010 22:25:04 -0800 Message-ID: <290865fd1001252225pfc56fd8y53db1865d8512080@mail.gmail.com> From: alan yang To: "M. Warner Losh" Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-mips@freebsd.org Subject: Re: Cavium port X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2010 06:25:06 -0000 hi, Warner, I got things setup to load kernel, but encountered the following, wonder what should I provide next that people could help shed some light on work around: kernel version, repository used,...or where to start looking at things ... many thanks! ---- U-Boot 1.1.1 (U-boot build #: 176) (SDK version: 1.7.1-240) (Build time: Feb 1) EBT5800 board revision major:2, minor:0, serial #: 2008-2.0-00251 OCTEON CN5860-NSP pass 1.1, Core clock: 600 MHz, DDR clock: 400 MHz (800 Mhz da) DRAM: 2048 MB Flash: 8 MB Clearing DRAM........ done BIST check passed. Net: octeth0, octeth1, octeth2, octeth3 Bus 0 (CF Card): OK ide 0: Model: 1024MB CompactFlash Card Firm: CF_A408J Ser#: A181109948O0040368 Type: Hard Disk Capacity: 977.4 MB = 0.9 GB (2001888 x 512) Octeon ebt5800# fatload ide 0 0 kernel reading kernel 4045856 bytes read Octeon ebt5800# bootoctlinux mem=0 numcores=1 argv[2]: numcores=1 ELF file is 64 bit Error allocating memory for elf image! ## Loading Linux kernel with entry point: 0x20000000 ... Bootloader: Done loading app on coremask: 0x1 From owner-freebsd-mips@FreeBSD.ORG Tue Jan 26 09:47:50 2010 Return-Path: Delivered-To: freebsd-mips@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AF42D106566B for ; Tue, 26 Jan 2010 09:47:50 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-iw0-f204.google.com (mail-iw0-f204.google.com [209.85.223.204]) by mx1.freebsd.org (Postfix) with ESMTP id 733378FC14 for ; Tue, 26 Jan 2010 09:47:50 +0000 (UTC) Received: by iwn42 with SMTP id 42so1420956iwn.9 for ; Tue, 26 Jan 2010 01:47:49 -0800 (PST) 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:content-transfer-encoding; bh=XawEb1lPkuOw+kgzjSVM7zldKuga380tfVhPLDFzRHQ=; b=L1HBKaJaY7/heADy6KQqXNOEjroTPQj7u9+7Z0WMBE4xNlqx2MemFE/0B1YGA34Mgl f6pF4BLaGQw6/HPVSd+jgC4PvXuahcoX0vRLNjjDcqmn8N9f6w+KvRpOa1paDXJMGmn7 5eX+lnPTp1teMrLLHyGgE6WDAQJRCRzmbAgX0= 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 :content-transfer-encoding; b=RR+giH64hn2yRRXpdO8EmCaG1q8Yxiovkck1wxGJY7JLkMiO5JUXfBeyfMxgMu8a8k nSH4a8wFV7WJn13FBYL21C+a7qqepnF3xHkAQ5iOcWVd72QuqymRFDvbcMEnd++sOouk 9+ktcCE43hC3BbLAj/2an3qCn1l8f1lwBGdEo= MIME-Version: 1.0 Sender: asmrookie@gmail.com Received: by 10.231.155.18 with SMTP id q18mr1805586ibw.80.1264497934939; Tue, 26 Jan 2010 01:25:34 -0800 (PST) In-Reply-To: <3bbf2fe11001260124h423bd73ev38ba939d34155c54@mail.gmail.com> References: <5D3E417C-FE51-49A7-B8CC-564932BF0D3E@lakerest.net> <489828.45501.qm@web34403.mail.mud.yahoo.com> <3bbf2fe11001260124h423bd73ev38ba939d34155c54@mail.gmail.com> Date: Tue, 26 Jan 2010 10:25:34 +0100 X-Google-Sender-Auth: 90cfe5433151ea5d Message-ID: <3bbf2fe11001260125t43b833feha759555f3e4d0fe8@mail.gmail.com> From: Attilio Rao To: Neelkanth Natu Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-mips@freebsd.org Subject: Re: AR71XX RTC X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2010 09:47:50 -0000 2010/1/26 Attilio Rao : > 2010/1/25 Neelkanth Natu : >> Hi Randall, >> >> --- On Mon, 1/25/10, Randall Stewart wrote: >> >>> From: Randall Stewart >>> Subject: Re: AR71XX RTC >>> To: "Neelkanth Natu" >>> Cc: "M. Warner Losh" , freebsd-mips@freebsd.org >>> Date: Monday, January 25, 2010, 12:51 PM >>> Neil: >>> >>> Thanks for the patch.. it does look good since the old >>> code was tromping part of the old threads PCB which is >>> definitely not right ;-0 .. I do have a question for you.. >>> forgive my ignorance.. >>> >>> What exactly are we trying to switch here. It seems >>> that cpu_switch(...) is now being called with >>> oldtd, newtd and mtx... >>> >>> I see that the thread structure has a struct mutex *td_lock >>> as >>> its first member. But what is this supposed to be pointing >>> to? >>> And when we switch are we trying to take the >>> >>> oldtd->td_lock and place it into the newtd->td_lock >>> >>> Or? >>> >>> What... I guess I just don't have any context for whats >>> going on.. >>> >> >> I am not very sure about this myself so take this with a grain of salt: >> >> When a thread is being switched out because it is on a sleep queue the >> intent is that some other thread running on a different cpu should not b= e >> allowed to muck with this thread's state. To make this happen the 'td_lo= ck' >> of 'oldtd' is switched from what it was originally (viz. the sleep queue >> chain lock) to 'blocked_lock'. The 'blocked_lock' is special because >> it is always locked. This all happens in sched_switch(). >> >> cpu_switch() is passed the original value of 'oldtd->td_lock' >> as the third argument. When the context is switched to 'newtd' we will >> switch back the 'oldtd->td_lock' from 'blocked_lock' to its original >> value. And this way we don't lose any wakeups that may happen while we >> are in sched_switch(). >> >> At least that is my very naive understanding of it. CCing Attilio to >> shed more light on this. > > Hope this little explanation may give more guidance: > http://lists.freebsd.org/pipermail/svn-src-head/2010-January/014038.html > > anyways, the interesting bits in, eg. i386 are: > > #if defined(SMP) && defined(SCHED_ULE) > #define SETOP =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 xchgl > #define BLOCK_SPIN(reg) =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 \ > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0movl =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0$blocked_lock,%eax ; =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0\ > =C2=A0 =C2=A0 =C2=A0 =C2=A0100: ; =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0\ > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0lock ; =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0\ > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0cmpxchgl =C2=A0 = =C2=A0 =C2=A0 =C2=A0%eax,TD_LOCK(reg) ; =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 \ > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0jne =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 101f ; =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0\ > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0pause ; =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 \ > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0jmp =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 100b ; =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0\ > =C2=A0 =C2=A0 =C2=A0 =C2=A0101: > #else > #define SETOP =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 movl > #define BLOCK_SPIN(reg) > #endif > > The difference with SETOP is just for providing a rel memory barriers > vs. not providing a rel memory barrier (thus be careful, if you want > to support ULE, to follow the same logic), while BLOCK_SPIN() does: > > while (oldtd->td_lock =3D=3D &blocked_lock) cpu_spinwait(); s/oldtd/newtd. Attilio --=20 Peace can only be achieved by understanding - A. Einstein From owner-freebsd-mips@FreeBSD.ORG Tue Jan 26 09:54:11 2010 Return-Path: Delivered-To: freebsd-mips@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 323FF1065692 for ; Tue, 26 Jan 2010 09:54:11 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-iw0-f204.google.com (mail-iw0-f204.google.com [209.85.223.204]) by mx1.freebsd.org (Postfix) with ESMTP id ECF9C8FC16 for ; Tue, 26 Jan 2010 09:54:10 +0000 (UTC) Received: by iwn42 with SMTP id 42so1423933iwn.9 for ; Tue, 26 Jan 2010 01:54:10 -0800 (PST) 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=VxiYGSyyRuHWjNqch2q6NBUpisvO1Q0+kvYhWXBBQFA=; b=UtvQiAUysfcfWak/ybya0sxaURVDA8VcSTUWYeJr2dGPQ7FzgcZWN//ZC2TxHn88Le qQOIxphaDEGKTvqHZz73jssL6orj3u/XQOrVnD2AzhhkAm4b9Z1fbVSJFrDC1Gf5SNyt f7a2MSKztz/zGe3aA/1sKRuxstgfJiSbTAB2A= 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=fQGmFRYNRnn9zoQUCLwoJAbbCCFk08gPWEm5NgJcRy/M5CigGw5bR24XRhAJHIp2Ob sn9aRwdTvy1AjRAG4tcePJZVD+eGtQeMXbi51xMRMboYTh8iNfZ1b91CuVZUeM9Gye8A 6d1B/Ng8hRXFtxCzfFQDjUAE3p5w5iisbSqWs= MIME-Version: 1.0 Sender: asmrookie@gmail.com Received: by 10.231.146.134 with SMTP id h6mr692569ibv.16.1264497847271; Tue, 26 Jan 2010 01:24:07 -0800 (PST) In-Reply-To: <489828.45501.qm@web34403.mail.mud.yahoo.com> References: <5D3E417C-FE51-49A7-B8CC-564932BF0D3E@lakerest.net> <489828.45501.qm@web34403.mail.mud.yahoo.com> Date: Tue, 26 Jan 2010 10:24:07 +0100 X-Google-Sender-Auth: 28e5667ff36f5ac7 Message-ID: <3bbf2fe11001260124h423bd73ev38ba939d34155c54@mail.gmail.com> From: Attilio Rao To: Neelkanth Natu Content-Type: text/plain; charset=UTF-8 Cc: freebsd-mips@freebsd.org Subject: Re: AR71XX RTC X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2010 09:54:11 -0000 2010/1/25 Neelkanth Natu : > Hi Randall, > > --- On Mon, 1/25/10, Randall Stewart wrote: > >> From: Randall Stewart >> Subject: Re: AR71XX RTC >> To: "Neelkanth Natu" >> Cc: "M. Warner Losh" , freebsd-mips@freebsd.org >> Date: Monday, January 25, 2010, 12:51 PM >> Neil: >> >> Thanks for the patch.. it does look good since the old >> code was tromping part of the old threads PCB which is >> definitely not right ;-0 .. I do have a question for you.. >> forgive my ignorance.. >> >> What exactly are we trying to switch here. It seems >> that cpu_switch(...) is now being called with >> oldtd, newtd and mtx... >> >> I see that the thread structure has a struct mutex *td_lock >> as >> its first member. But what is this supposed to be pointing >> to? >> And when we switch are we trying to take the >> >> oldtd->td_lock and place it into the newtd->td_lock >> >> Or? >> >> What... I guess I just don't have any context for whats >> going on.. >> > > I am not very sure about this myself so take this with a grain of salt: > > When a thread is being switched out because it is on a sleep queue the > intent is that some other thread running on a different cpu should not be > allowed to muck with this thread's state. To make this happen the 'td_lock' > of 'oldtd' is switched from what it was originally (viz. the sleep queue > chain lock) to 'blocked_lock'. The 'blocked_lock' is special because > it is always locked. This all happens in sched_switch(). > > cpu_switch() is passed the original value of 'oldtd->td_lock' > as the third argument. When the context is switched to 'newtd' we will > switch back the 'oldtd->td_lock' from 'blocked_lock' to its original > value. And this way we don't lose any wakeups that may happen while we > are in sched_switch(). > > At least that is my very naive understanding of it. CCing Attilio to > shed more light on this. Hope this little explanation may give more guidance: http://lists.freebsd.org/pipermail/svn-src-head/2010-January/014038.html anyways, the interesting bits in, eg. i386 are: #if defined(SMP) && defined(SCHED_ULE) #define SETOP xchgl #define BLOCK_SPIN(reg) \ movl $blocked_lock,%eax ; \ 100: ; \ lock ; \ cmpxchgl %eax,TD_LOCK(reg) ; \ jne 101f ; \ pause ; \ jmp 100b ; \ 101: #else #define SETOP movl #define BLOCK_SPIN(reg) #endif The difference with SETOP is just for providing a rel memory barriers vs. not providing a rel memory barrier (thus be careful, if you want to support ULE, to follow the same logic), while BLOCK_SPIN() does: while (oldtd->td_lock == &blocked_lock) cpu_spinwait(); still enforcing an acq memory barrier on it. Then you may see when these functions are used, but that should be very MD specific. Attilio -- Peace can only be achieved by understanding - A. Einstein From owner-freebsd-mips@FreeBSD.ORG Tue Jan 26 14:47:40 2010 Return-Path: Delivered-To: freebsd-mips@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 30E441065672 for ; Tue, 26 Jan 2010 14:47:40 +0000 (UTC) (envelope-from aduane@juniper.net) Received: from exprod7og123.obsmtp.com (exprod7og123.obsmtp.com [64.18.2.24]) by mx1.freebsd.org (Postfix) with ESMTP id D0F148FC08 for ; Tue, 26 Jan 2010 14:47:39 +0000 (UTC) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob123.postini.com ([64.18.6.12]) with SMTP ID DSNKS18Ai/7W8tgRvIYGCwccR+DA6gk8BWVd@postini.com; Tue, 26 Jan 2010 06:47:39 PST Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.1.393.1; Tue, 26 Jan 2010 06:27:06 -0800 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe01-wf.jnpr.net ([fe80::d0d1:653d:5b91:a123%11]) with mapi; Tue, 26 Jan 2010 09:27:06 -0500 From: Andrew Duane To: alan yang , "M. Warner Losh" Date: Tue, 26 Jan 2010 09:27:05 -0500 Thread-Topic: Cavium port Thread-Index: AcqeUFLZVP6uzum6SLKYnkv0tfFJIgAQyvzg Message-ID: References: <290865fd1001051526i73dd96d7x18a7a842b903b61d@mail.gmail.com> <4B4433ED.10103@mahan.org> <290865fd1001211445n1b469e11o2f37598c989dbaf7@mail.gmail.com> <20100121.163312.886429907199307448.imp@bsdimp.com> <290865fd1001252225pfc56fd8y53db1865d8512080@mail.gmail.com> In-Reply-To: <290865fd1001252225pfc56fd8y53db1865d8512080@mail.gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "freebsd-mips@freebsd.org" Subject: RE: Cavium port X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2010 14:47:40 -0000 owner-freebsd-mips@freebsd.org wrote: > hi, Warner, >=20 > I got things setup to load kernel, but encountered the following, > wonder what should I provide next that people could help shed some > light on work around: kernel version, repository used,...or where to > start looking at things ...=20 >=20 > many thanks! >=20 > ---- >=20 > U-Boot 1.1.1 (U-boot build #: 176) (SDK version: 1.7.1-240) (Build > time: Feb 1)=20 >=20 > EBT5800 board revision major:2, minor:0, serial #: 2008-2.0-00251 > OCTEON CN5860-NSP pass 1.1, Core clock: 600 MHz, DDR clock: 400 MHz > (800 Mhz da) DRAM: 2048 MB > Flash: 8 MB > Clearing DRAM........ done > BIST check passed. > Net: octeth0, octeth1, octeth2, octeth3 > Bus 0 (CF Card): OK >=20 > ide 0: Model: 1024MB CompactFlash Card Firm: CF_A408J Ser#: > A181109948O0040368 Type: Hard Disk > Capacity: 977.4 MB =3D 0.9 GB (2001888 x 512) > Octeon ebt5800# fatload ide 0 0 kernel > reading kernel >=20 > 4045856 bytes read > Octeon ebt5800# bootoctlinux mem=3D0 numcores=3D1 > argv[2]: numcores=3D1 > ELF file is 64 bit > Error allocating memory for elf image! > ## Loading Linux kernel with entry point: 0x20000000 ... > Bootloader: Done loading app on coremask: 0x1 > _______________________________________________ > freebsd-mips@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-mips > To unsubscribe, send any mail to > "freebsd-mips-unsubscribe@freebsd.org" IIRC, you do not load at address 0 (fatload ide 0 >>>0<<< kernel), isn't th= e default address 0x100000? It's been too long since I used the eval boards, but I think I remember tha= t. /Andrew From owner-freebsd-mips@FreeBSD.ORG Tue Jan 26 14:55:43 2010 Return-Path: Delivered-To: freebsd-mips@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 480E31065670 for ; Tue, 26 Jan 2010 14:55:43 +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 07F878FC15 for ; Tue, 26 Jan 2010 14:55:42 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.3/8.14.1) with ESMTP id o0QEkgVA071703; Tue, 26 Jan 2010 07:46:42 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Tue, 26 Jan 2010 07:47:32 -0700 (MST) Message-Id: <20100126.074732.321689434066232630.imp@bsdimp.com> To: aduane@juniper.net From: "M. Warner Losh" In-Reply-To: References: <20100121.163312.886429907199307448.imp@bsdimp.com> <290865fd1001252225pfc56fd8y53db1865d8512080@mail.gmail.com> X-Mailer: Mew version 6.3 on Emacs 22.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-mips@FreeBSD.org Subject: Re: Cavium port X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2010 14:55:43 -0000 In message: Andrew Duane writes: : owner-freebsd-mips@freebsd.org wrote: : > hi, Warner, : > : > I got things setup to load kernel, but encountered the following, : > wonder what should I provide next that people could help shed some : > light on work around: kernel version, repository used,...or where to : > start looking at things ... : > : > many thanks! : > : > ---- : > : > U-Boot 1.1.1 (U-boot build #: 176) (SDK version: 1.7.1-240) (Build : > time: Feb 1) : > : > EBT5800 board revision major:2, minor:0, serial #: 2008-2.0-00251 : > OCTEON CN5860-NSP pass 1.1, Core clock: 600 MHz, DDR clock: 400 MHz : > (800 Mhz da) DRAM: 2048 MB : > Flash: 8 MB : > Clearing DRAM........ done : > BIST check passed. : > Net: octeth0, octeth1, octeth2, octeth3 : > Bus 0 (CF Card): OK : > : > ide 0: Model: 1024MB CompactFlash Card Firm: CF_A408J Ser#: : > A181109948O0040368 Type: Hard Disk : > Capacity: 977.4 MB = 0.9 GB (2001888 x 512) : > Octeon ebt5800# fatload ide 0 0 kernel : > reading kernel : > : > 4045856 bytes read : > Octeon ebt5800# bootoctlinux mem=0 numcores=1 : > argv[2]: numcores=1 : > ELF file is 64 bit : > Error allocating memory for elf image! : > ## Loading Linux kernel with entry point: 0x20000000 ... : > Bootloader: Done loading app on coremask: 0x1 : > _______________________________________________ : > freebsd-mips@freebsd.org mailing list : > http://lists.freebsd.org/mailman/listinfo/freebsd-mips : > To unsubscribe, send any mail to : > "freebsd-mips-unsubscribe@freebsd.org" : : IIRC, you do not load at address 0 (fatload ide 0 >>>0<<< kernel), isn't the default address 0x100000? : It's been too long since I used the eval boards, but I think I remember that. I load the kernel at a800000 on my CN3800 board. Warner From owner-freebsd-mips@FreeBSD.ORG Tue Jan 26 15:43:26 2010 Return-Path: Delivered-To: freebsd-mips@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9AE34106568D for ; Tue, 26 Jan 2010 15:43:26 +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 583A38FC14 for ; Tue, 26 Jan 2010 15:43:26 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.3/8.14.1) with ESMTP id o0QFVAEm072361; Tue, 26 Jan 2010 08:31:10 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Tue, 26 Jan 2010 08:31:59 -0700 (MST) Message-Id: <20100126.083159.145758949487376772.imp@bsdimp.com> To: alancyang@gmail.com From: "M. Warner Losh" In-Reply-To: <290865fd1001252225pfc56fd8y53db1865d8512080@mail.gmail.com> References: <290865fd1001211445n1b469e11o2f37598c989dbaf7@mail.gmail.com> <20100121.163312.886429907199307448.imp@bsdimp.com> <290865fd1001252225pfc56fd8y53db1865d8512080@mail.gmail.com> X-Mailer: Mew version 6.3 on Emacs 22.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-mips@freebsd.org Subject: Re: Cavium port X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2010 15:43:26 -0000 In message: <290865fd1001252225pfc56fd8y53db1865d8512080@mail.gmail.com> alan yang writes: : hi, Warner, : : I got things setup to load kernel, but encountered the following, : wonder what should I provide next that people could help shed some : light on work around: kernel version, repository used,...or where to : start looking at things ... : : many thanks! I've written up what I do on my CN3800 board (the ebt-3000) on my blog. You may need to try a different address than a800000 for different boards and/or processors, and if so, please let me know. http://bsdimp.blogspot.com/2010/01/booting-instructions-for-freebsd-on.html Warner : ---- : : U-Boot 1.1.1 (U-boot build #: 176) (SDK version: 1.7.1-240) (Build time: Feb 1) : : EBT5800 board revision major:2, minor:0, serial #: 2008-2.0-00251 : OCTEON CN5860-NSP pass 1.1, Core clock: 600 MHz, DDR clock: 400 MHz (800 Mhz da) : DRAM: 2048 MB : Flash: 8 MB : Clearing DRAM........ done : BIST check passed. : Net: octeth0, octeth1, octeth2, octeth3 : Bus 0 (CF Card): OK : : ide 0: Model: 1024MB CompactFlash Card Firm: CF_A408J Ser#: A181109948O0040368 : Type: Hard Disk : Capacity: 977.4 MB = 0.9 GB (2001888 x 512) : Octeon ebt5800# fatload ide 0 0 kernel : reading kernel : : 4045856 bytes read : Octeon ebt5800# bootoctlinux mem=0 numcores=1 : argv[2]: numcores=1 : ELF file is 64 bit : Error allocating memory for elf image! : ## Loading Linux kernel with entry point: 0x20000000 ... : Bootloader: Done loading app on coremask: 0x1 : : From owner-freebsd-mips@FreeBSD.ORG Tue Jan 26 17:30:40 2010 Return-Path: Delivered-To: freebsd-mips@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 43EBD1065693 for ; Tue, 26 Jan 2010 17:30:40 +0000 (UTC) (envelope-from alancyang@gmail.com) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by mx1.freebsd.org (Postfix) with ESMTP id 096B98FC17 for ; Tue, 26 Jan 2010 17:30:39 +0000 (UTC) Received: by pwi15 with SMTP id 15so3373783pwi.3 for ; Tue, 26 Jan 2010 09:30:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=OvOHgOE312Fp5B5vsmInG+roNy6zkCiFabhEgyUoSbg=; b=ihSF8PIx9fk/exJhJJvUvVAejWGQM39Aexa698LAXsurGlxN1+ZI8sBmL3drniBLzO O77MPE8ROG/LMoorwmD/fxthyIwltTGF2VDiD02mnQwbrRmcHRXq6O9d8X+PQl8b3g4L OQgVHSKP3EWr8BxSp8OY2TD7jQxCdYqMSp37k= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=PwhDTtL3ac95R9JE6mZFM+Rm00DKhT6Lf5Le58Hsp4XYjInr5dpTxOwnKBbz1mC3hv 9XUjg2uEoRwvkJgntgGi/2jZ3gzqh3UxJq470ZsBGX0GZn4dykE5XvoeHzH41CRw3yfX D/vLCQMZ2UmK0WsPiTdIxghK09yxIQsv9rBbI= MIME-Version: 1.0 Received: by 10.114.250.11 with SMTP id x11mr5668240wah.205.1264527039513; Tue, 26 Jan 2010 09:30:39 -0800 (PST) In-Reply-To: <20100126.074732.321689434066232630.imp@bsdimp.com> References: <20100121.163312.886429907199307448.imp@bsdimp.com> <290865fd1001252225pfc56fd8y53db1865d8512080@mail.gmail.com> <20100126.074732.321689434066232630.imp@bsdimp.com> Date: Tue, 26 Jan 2010 09:30:38 -0800 Message-ID: <290865fd1001260930p6b0e2a08l82be4f1d94c1e8@mail.gmail.com> From: alan yang To: "M. Warner Losh" Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-mips@freebsd.org Subject: Re: Cavium port X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2010 17:30:40 -0000 i could load 64bit linux kernel at address 0, so thought maybe freebsd kernel could load same way. address 100000, a80000 tried but no luck. wonder people have played with ebt5800 ... ---- Octeon ebt5800# fatload ide 0 100000 kernel reading kernel 4045856 bytes read WARNING: Data loaded outside of the reserved load area, memory corruption may o. WARNING: Please refer to the bootloader memory map documentation for more infor. Octeon ebt5800# bootoctlinux 100000 numcores=1 argv[2]: numcores=1 ## No elf image at address 0x00100000 From owner-freebsd-mips@FreeBSD.ORG Tue Jan 26 18:09:17 2010 Return-Path: Delivered-To: freebsd-mips@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 489C1106568D for ; Tue, 26 Jan 2010 18:09:17 +0000 (UTC) (envelope-from jrytoung@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.154]) by mx1.freebsd.org (Postfix) with ESMTP id CD8988FC18 for ; Tue, 26 Jan 2010 18:09:16 +0000 (UTC) Received: by fg-out-1718.google.com with SMTP id e12so768485fga.13 for ; Tue, 26 Jan 2010 10:09:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=Qu7BOBsI3hSc+IU7ob7UyacnbbMg5ILBtfGbzrMzngA=; b=o3gGBKyQOZsy4D1G5LWngDYvC2jUitI8VVzEG49KAmK0xnRe0lf071sdBRArK1boQ2 Ap2zhFW+WkhxAeStnjttP5LxzfLaifQXFWNzecj7GerWIMmodYFw5GJiGORg4oSqLIln Jbu0dDk8WXTGZzaEAGbYylwr2xRCqT1qghGUw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=H5gfNYSwX3rgiSiKdLs83IFFShyNFC5MkaZ1bKAeoSDxwiLJI6ZuZB352w8a3vysbX TNNojCcavXqabaOyIDfvjapKQb6QJPb0MYfvYUIfyRxylalSpr0c1I4fOYj63lW7gtBe 1rJ4hWdljP3DuZvdTE5LQbSZkp01KC+l4NQ8I= MIME-Version: 1.0 Received: by 10.216.87.6 with SMTP id x6mr98718wee.174.1264527744558; Tue, 26 Jan 2010 09:42:24 -0800 (PST) In-Reply-To: <290865fd1001260930p6b0e2a08l82be4f1d94c1e8@mail.gmail.com> References: <20100121.163312.886429907199307448.imp@bsdimp.com> <290865fd1001252225pfc56fd8y53db1865d8512080@mail.gmail.com> <20100126.074732.321689434066232630.imp@bsdimp.com> <290865fd1001260930p6b0e2a08l82be4f1d94c1e8@mail.gmail.com> Date: Tue, 26 Jan 2010 09:42:24 -0800 Message-ID: <86068e731001260942j345d9f55i7e602a172e0838ac@mail.gmail.com> From: Jerry Toung To: alan yang Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-mips@freebsd.org Subject: Re: Cavium port X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2010 18:09:17 -0000 i have an CN-EBT-5800 eval board. I haven't run fatload in while (over 1 year), but with tftp, here is the command tftp 21000000 kernelname;bootoctlinux 21000000 if you have a FreeBSD SMP kernel, the command would be tftp 21000000 kernelname;bootoctlinux 21000000 coremask=0xfe i hope that'll help. Jerry From owner-freebsd-mips@FreeBSD.ORG Tue Jan 26 22:19:31 2010 Return-Path: Delivered-To: freebsd-mips@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 31F83106566C for ; Tue, 26 Jan 2010 22:19:31 +0000 (UTC) (envelope-from dancholazarov@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 B10B78FC0C for ; Tue, 26 Jan 2010 22:19:30 +0000 (UTC) Received: by ewy10 with SMTP id 10so516229ewy.3 for ; Tue, 26 Jan 2010 14:19:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=S1eKOb0uotup6xMhvWuk2YVZLz9L1NxU//b+Jnz+lms=; b=Bnlue/aYeuq/ZT9c5PP7CKwa758EfB5WWk3s0YsPRQ9kVxNqSGnqONjMDZHDSTpQDL 29BTsWtut0cxUORBkkidnczVJABJHLqowg+RN2fP2UdMp5Iaj1a5siBTLavyPYaGvAxI MXeKoI8gwJYZhM9MUbEL1bT+3VZQPqyyBC0bo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=sUIMmS54MUbPGSsrOnXH+TLYzlPb6U7qX/ZPrWJ26KKUHOiH132xTnnnwLtCblfb0w vNL3snsBB2ISEKSpfchvkqFRz+vZ58xODQQc0i57QFTdTYCN1jQ5ghRyZxM9tkNYB9xD pEw6beVIU8I7b3M+bGCPfYeD9Gjh4YSfbIbu0= MIME-Version: 1.0 Received: by 10.213.47.6 with SMTP id l6mr3210872ebf.58.1264542474081; Tue, 26 Jan 2010 13:47:54 -0800 (PST) In-Reply-To: <86068e731001260942j345d9f55i7e602a172e0838ac@mail.gmail.com> References: <20100121.163312.886429907199307448.imp@bsdimp.com> <290865fd1001252225pfc56fd8y53db1865d8512080@mail.gmail.com> <20100126.074732.321689434066232630.imp@bsdimp.com> <290865fd1001260930p6b0e2a08l82be4f1d94c1e8@mail.gmail.com> <86068e731001260942j345d9f55i7e602a172e0838ac@mail.gmail.com> Date: Tue, 26 Jan 2010 22:47:53 +0100 Message-ID: <885d28551001261347i5bb1d502p330ef8f328588796@mail.gmail.com> From: Yordan Lazarov To: Jerry Toung Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-mips@freebsd.org Subject: Re: Cavium port X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2010 22:19:31 -0000 Hello, It depends what version of the u-boot you use, but in general the following commands should work: tftpload $(loadaddr) kerrel; bootoctlin $(loadaddr) coremask=0x1 or tftpload 21000000 kerrel; bootoctlin 21000000 coremask=0x1 On 1/26/10, Jerry Toung wrote: > i have an CN-EBT-5800 eval board. > I haven't run fatload in while (over 1 year), but with tftp, here is the > command > > tftp 21000000 kernelname;bootoctlinux 21000000 > > if you have a FreeBSD SMP kernel, the command would be > > tftp 21000000 kernelname;bootoctlinux 21000000 coremask=0xfe > > i hope that'll help. > > Jerry > _______________________________________________ > freebsd-mips@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-mips > To unsubscribe, send any mail to "freebsd-mips-unsubscribe@freebsd.org" > From owner-freebsd-mips@FreeBSD.ORG Wed Jan 27 05:30:24 2010 Return-Path: Delivered-To: freebsd-mips@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8E9B6106566C for ; Wed, 27 Jan 2010 05:30:24 +0000 (UTC) (envelope-from alancyang@gmail.com) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by mx1.freebsd.org (Postfix) with ESMTP id 60CC38FC26 for ; Wed, 27 Jan 2010 05:30:24 +0000 (UTC) Received: by pwi15 with SMTP id 15so3793301pwi.3 for ; Tue, 26 Jan 2010 21:30:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=tTFe2jRvMZrpKxWwBUyVWSkty/4xHbyMRPUm91/PwfM=; b=iNSU+8lNSF+ZiaJh9eXPGXV0DIUmNk/xhPDINJiXgw4bu77i5ltq7rFyhopdX5STB9 Fz8Ryd7ma1JEtRg5KvtsmuP4/5PZZ/60RTEQeXR/88l8S/oXhp2J31AFrzlvXSdxo5jh CUyfP0TJeo0T6AQ1MQ3DTg+CsCxYPPzlFfNyg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=fHDnURJIHMQ8oWZ51TeDwQVyTVslVotOKsteRHjuNeIRIZKvf5YwAGyj8SzeloAk/7 kbwDCIUJnpOMHaJhs4o6tzgYRQpQeagkaUOa2Dzxrh8u+gZvtzJOn8D+NUpIB081/i21 Y7JeFg6YSU779f4acpAnPTDGt5JMT0fAHKQoI= MIME-Version: 1.0 Received: by 10.114.187.7 with SMTP id k7mr6197261waf.153.1264570223792; Tue, 26 Jan 2010 21:30:23 -0800 (PST) In-Reply-To: <885d28551001261347i5bb1d502p330ef8f328588796@mail.gmail.com> References: <20100121.163312.886429907199307448.imp@bsdimp.com> <290865fd1001252225pfc56fd8y53db1865d8512080@mail.gmail.com> <20100126.074732.321689434066232630.imp@bsdimp.com> <290865fd1001260930p6b0e2a08l82be4f1d94c1e8@mail.gmail.com> <86068e731001260942j345d9f55i7e602a172e0838ac@mail.gmail.com> <885d28551001261347i5bb1d502p330ef8f328588796@mail.gmail.com> Date: Tue, 26 Jan 2010 21:30:23 -0800 Message-ID: <290865fd1001262130u29272ff8ve6d50a45e27a43e4@mail.gmail.com> From: alan yang To: Yordan Lazarov Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-mips@freebsd.org Subject: Re: Cavium port X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jan 2010 05:30:24 -0000 still cannot get kernel to boot..., don't know the cause 'Error allocating memory for elf image' is due to my kernel... or something else. really want to get freebsd up and running. thanks in advance again for people's help!! -- U-Boot 1.1.1 (U-boot build #: 176) (SDK version: 1.7.1-240) (Build time: Feb ) EBT5800 board revision major:2, minor:0, serial #: 2008-2.0-00251 OCTEON CN5860-NSP pass 1.1, Core clock: 600 MHz, DDR clock: 400 MHz (800 Mhz d) DRAM: 2048 MB Flash: 8 MB Clearing DRAM........ done BIST check passed. Net: octeth0, octeth1, octeth2, octeth3 Bus 0 (CF Card): OK ide 0: Model: 1024MB CompactFlash Card Firm: CF_A408J Ser#: A181109948O004038 Type: Hard Disk Capacity: 977.4 MB = 0.9 GB (2001888 x 512) Octeon ebt5800# fatload ide 0 21000000 kernel reading kernel 4045856 bytes read Octeon ebt5800# bootoctlinux 21000000 coremask=0x1 argv[2]: coremask=0x1 ELF file is 64 bit Error allocating memory for elf image! ## Loading Linux kernel with entry point: 0x21000000 ... Bootloader: Done loading app on coremask: 0x1 From owner-freebsd-mips@FreeBSD.ORG Wed Jan 27 05:45:56 2010 Return-Path: Delivered-To: freebsd-mips@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F1D9D10656A3 for ; Wed, 27 Jan 2010 05:45:56 +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 9580B8FC17 for ; Wed, 27 Jan 2010 05:45:56 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.3/8.14.1) with ESMTP id o0R5fvVS082644; Tue, 26 Jan 2010 22:41:57 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Tue, 26 Jan 2010 22:42:48 -0700 (MST) Message-Id: <20100126.224248.925196285497011965.imp@bsdimp.com> To: alancyang@gmail.com From: "M. Warner Losh" In-Reply-To: <290865fd1001262130u29272ff8ve6d50a45e27a43e4@mail.gmail.com> References: <86068e731001260942j345d9f55i7e602a172e0838ac@mail.gmail.com> <885d28551001261347i5bb1d502p330ef8f328588796@mail.gmail.com> <290865fd1001262130u29272ff8ve6d50a45e27a43e4@mail.gmail.com> X-Mailer: Mew version 6.3 on Emacs 22.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-mips@freebsd.org Subject: Re: Cavium port X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jan 2010 05:45:57 -0000 In message: <290865fd1001262130u29272ff8ve6d50a45e27a43e4@mail.gmail.com> alan yang writes: : still cannot get kernel to boot..., don't know the cause 'Error : allocating memory for elf image' is due to my kernel... or something : else. I'm not sure. Are you using the OCTEON1-32 or OCTEON1 kernel? From the below, it says 'ELF file is 64-bit.' While we want the 64-bit stuff to go, there's a fair amount of work there that we need to do/port yet to make it go. Try building the OCTEON1-32 kernel instead. : really want to get freebsd up and running. I'd love you to get it up and running to. There's still one or two minor gotchas with interrupts (see my blog at bsdimp.blogpot.com for details on the current workaround), but you can easily get to single user today. Warner : thanks in advance again for people's help!! : -- : : U-Boot 1.1.1 (U-boot build #: 176) (SDK version: 1.7.1-240) (Build time: Feb ) : : EBT5800 board revision major:2, minor:0, serial #: 2008-2.0-00251 : OCTEON CN5860-NSP pass 1.1, Core clock: 600 MHz, DDR clock: 400 MHz (800 Mhz d) : DRAM: 2048 MB : Flash: 8 MB : Clearing DRAM........ done : BIST check passed. : Net: octeth0, octeth1, octeth2, octeth3 : Bus 0 (CF Card): OK : : ide 0: Model: 1024MB CompactFlash Card Firm: CF_A408J Ser#: A181109948O004038 : Type: Hard Disk : Capacity: 977.4 MB = 0.9 GB (2001888 x 512) : Octeon ebt5800# fatload ide 0 21000000 kernel : reading kernel : : 4045856 bytes read : Octeon ebt5800# bootoctlinux 21000000 coremask=0x1 : argv[2]: coremask=0x1 : ELF file is 64 bit : Error allocating memory for elf image! : ## Loading Linux kernel with entry point: 0x21000000 ... : Bootloader: Done loading app on coremask: 0x1 : _______________________________________________ : freebsd-mips@freebsd.org mailing list : http://lists.freebsd.org/mailman/listinfo/freebsd-mips : To unsubscribe, send any mail to "freebsd-mips-unsubscribe@freebsd.org" : : From owner-freebsd-mips@FreeBSD.ORG Wed Jan 27 06:35:13 2010 Return-Path: Delivered-To: freebsd-mips@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E0FFE1065670 for ; Wed, 27 Jan 2010 06:35:12 +0000 (UTC) (envelope-from alancyang@gmail.com) Received: from mail-pz0-f176.google.com (mail-pz0-f176.google.com [209.85.222.176]) by mx1.freebsd.org (Postfix) with ESMTP id B4F688FC16 for ; Wed, 27 Jan 2010 06:35:12 +0000 (UTC) Received: by pzk6 with SMTP id 6so244566pzk.3 for ; Tue, 26 Jan 2010 22:35:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=9HOMHyqHMf7OdpUCQL14eDDH+QhtSYbgcdeZpEeJOlQ=; b=Q4vf+oc5WpXznA6kJEvPxznrrL4xxCwEd9mbDHedMds0V1IW/9oicq2zUZ6/caGfo3 BFq+fPZJ8/WKKAkCs7yfl7/pGoen4Zeke+ARi4VWDYueeayU9LQd9Jk0J0u87ZQ2iTZ3 WiSDU5CvBHTEMl5TmeQAf31KE3lX/j1J/avmw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=G2Ronb6wUqkZ2DRhEQzfpN7HWuouPjKKS7LAOl+n2g/4uh/KeB3IDoxEjb0KgR6JAS rMHAGh7YumJvUqfu9x7zA5gHT7Dy0pepDdATA/GM7ksTVuKoT2j2BW3SEgqM0qiWY2v+ bJGTWLHmRw1sBvCKgmleZ6eQzk5tUACY/4VcY= MIME-Version: 1.0 Received: by 10.114.163.3 with SMTP id l3mr6229122wae.151.1264574112166; Tue, 26 Jan 2010 22:35:12 -0800 (PST) In-Reply-To: <20100126.224248.925196285497011965.imp@bsdimp.com> References: <86068e731001260942j345d9f55i7e602a172e0838ac@mail.gmail.com> <885d28551001261347i5bb1d502p330ef8f328588796@mail.gmail.com> <290865fd1001262130u29272ff8ve6d50a45e27a43e4@mail.gmail.com> <20100126.224248.925196285497011965.imp@bsdimp.com> Date: Tue, 26 Jan 2010 22:35:11 -0800 Message-ID: <290865fd1001262235m13ec4a2em863da596fd9a6c2@mail.gmail.com> From: alan yang To: "M. Warner Losh" Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-mips@freebsd.org Subject: Re: Cavium port X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jan 2010 06:35:13 -0000 hi, Warner, My kernel was built with OCTEON1 configuration file, and yes would like to give 32-bit kernel a try. Wonder you could help list the OCTEON1-32 configuration file used that i could modify OCTEON1 accordingly. Thanks! From owner-freebsd-mips@FreeBSD.ORG Wed Jan 27 16:20:19 2010 Return-Path: Delivered-To: freebsd-mips@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8D76F1065692 for ; Wed, 27 Jan 2010 16:20:19 +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 3746E8FC2A for ; Wed, 27 Jan 2010 16:20:19 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.3/8.14.1) with ESMTP id o0RG6Rpq091254; Wed, 27 Jan 2010 09:06:27 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Wed, 27 Jan 2010 09:07:18 -0700 (MST) Message-Id: <20100127.090718.131509470573849915.imp@bsdimp.com> To: alancyang@gmail.com From: "M. Warner Losh" In-Reply-To: <290865fd1001262235m13ec4a2em863da596fd9a6c2@mail.gmail.com> References: <290865fd1001262130u29272ff8ve6d50a45e27a43e4@mail.gmail.com> <20100126.224248.925196285497011965.imp@bsdimp.com> <290865fd1001262235m13ec4a2em863da596fd9a6c2@mail.gmail.com> X-Mailer: Mew version 6.3 on Emacs 22.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-mips@FreeBSD.org Subject: Re: Cavium port X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jan 2010 16:20:19 -0000 In message: <290865fd1001262235m13ec4a2em863da596fd9a6c2@mail.gmail.com> alan yang writes: : hi, Warner, : : My kernel was built with OCTEON1 configuration file, and yes would : like to give 32-bit kernel a try. : : Wonder you could help list the OCTEON1-32 configuration file used that : i could modify OCTEON1 accordingly. The OCTEON1-32 file is committed to the tree. I'll add some comments to it about which one to use for Cavium... Warner From owner-freebsd-mips@FreeBSD.ORG Thu Jan 28 14:20:34 2010 Return-Path: Delivered-To: freebsd-mips@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0C8E8106566C for ; Thu, 28 Jan 2010 14:20:34 +0000 (UTC) (envelope-from alancyang@gmail.com) Received: from mail-pz0-f176.google.com (mail-pz0-f176.google.com [209.85.222.176]) by mx1.freebsd.org (Postfix) with ESMTP id D5A148FC0C for ; Thu, 28 Jan 2010 14:20:33 +0000 (UTC) Received: by pzk6 with SMTP id 6so520469pzk.3 for ; Thu, 28 Jan 2010 06:20:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=e5llovutAam4q2Xcc8GYSoPBImftx1ThMyp3nssKF8o=; b=xut6TuhGBczmyDsO8GHYhmUCH07cQV4upVRaZ1azjvA9WEaXEg5mqnMKQWVDVgoOOC Cf4+2UwUt+4G5S7bvudwsvO+RCleetcEQiu1mvznrOXEnytHw4Mw2H1ET1xOezf9tZw5 WlDUSI2VKJpvRc4LrG+b3sNefAnOn/5TM/iUM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=xNu9+LT5E261XneMbElBpAbGyPdz3KNzDBDzz8HJly+69XxK/NN45bbLJbsq6o2kf/ OSKdEiRkn+NlC/NyBzhSYDhh3ow1N5iAaw0ITqzNO/L3aKm3vveJkW5qWqU3xMe7bTlz pEjzOk5ONUJ5WcGGoTPaEqATtNSVM9uUpVJFs= MIME-Version: 1.0 Received: by 10.114.251.31 with SMTP id y31mr641123wah.182.1264688433229; Thu, 28 Jan 2010 06:20:33 -0800 (PST) In-Reply-To: <20100127.090718.131509470573849915.imp@bsdimp.com> References: <290865fd1001262130u29272ff8ve6d50a45e27a43e4@mail.gmail.com> <20100126.224248.925196285497011965.imp@bsdimp.com> <290865fd1001262235m13ec4a2em863da596fd9a6c2@mail.gmail.com> <20100127.090718.131509470573849915.imp@bsdimp.com> Date: Thu, 28 Jan 2010 06:20:32 -0800 Message-ID: <290865fd1001280620p300e318bh848cb801d681ff40@mail.gmail.com> From: alan yang To: "M. Warner Losh" Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-mips@freebsd.org Subject: Re: Cavium port X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jan 2010 14:20:34 -0000 hi, Warner, Just noticed that you indicated to abandon project/mips branch now. For code base that I checked out from svn repo the project/mips branch on 10/14/2009, would you see problem if i just getting OCTEON1-32 conf file and build kernel from there, or should I at this time check out 9-CURRENT for octeon port I am interested in and track / follow that way. Thanks for the advise. From owner-freebsd-mips@FreeBSD.ORG Thu Jan 28 15:18:29 2010 Return-Path: Delivered-To: freebsd-mips@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 60E94106566B for ; Thu, 28 Jan 2010 15:18:29 +0000 (UTC) (envelope-from mahan@mahan.org) Received: from ns.mahan.org (ns.mahan.org [67.116.10.138]) by mx1.freebsd.org (Postfix) with ESMTP id 367268FC13 for ; Thu, 28 Jan 2010 15:18:29 +0000 (UTC) Received: from Gypsy.mahan.org (crowTrobot [67.116.10.140]) by ns.mahan.org (8.13.6/8.13.6) with ESMTP id o0SFJGaF073300; Thu, 28 Jan 2010 07:19:16 -0800 (PST) (envelope-from mahan@mahan.org) Message-ID: <4B61AABC.1070404@mahan.org> Date: Thu, 28 Jan 2010 07:18:20 -0800 From: Patrick Mahan User-Agent: Thunderbird 2.0.0.22 (X11/20090605) MIME-Version: 1.0 To: alan yang References: <290865fd1001051526i73dd96d7x18a7a842b903b61d@mail.gmail.com> <4B4433ED.10103@mahan.org> <290865fd1001211445n1b469e11o2f37598c989dbaf7@mail.gmail.com> <20100121.163312.886429907199307448.imp@bsdimp.com> <290865fd1001252225pfc56fd8y53db1865d8512080@mail.gmail.com> In-Reply-To: <290865fd1001252225pfc56fd8y53db1865d8512080@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-mips@freebsd.org Subject: Re: Cavium port X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jan 2010 15:18:29 -0000 Alan, I think you should try - fatload ide 0 $(loadaddr) kernel bootoctlinux $(loadaddr) loadaddr should be set by u-boot as the first usable memory address. do a printenv after you bring up the eval board. Patrick alan yang wrote: > hi, Warner, > > I got things setup to load kernel, but encountered the following, > wonder what should I provide next that people could help shed some > light on work around: kernel version, repository used,...or where to > start looking at things ... > > many thanks! > > ---- > > U-Boot 1.1.1 (U-boot build #: 176) (SDK version: 1.7.1-240) (Build time: Feb 1) > > EBT5800 board revision major:2, minor:0, serial #: 2008-2.0-00251 > OCTEON CN5860-NSP pass 1.1, Core clock: 600 MHz, DDR clock: 400 MHz (800 Mhz da) > DRAM: 2048 MB > Flash: 8 MB > Clearing DRAM........ done > BIST check passed. > Net: octeth0, octeth1, octeth2, octeth3 > Bus 0 (CF Card): OK > > ide 0: Model: 1024MB CompactFlash Card Firm: CF_A408J Ser#: A181109948O0040368 > Type: Hard Disk > Capacity: 977.4 MB = 0.9 GB (2001888 x 512) > Octeon ebt5800# fatload ide 0 0 kernel > reading kernel > > 4045856 bytes read > Octeon ebt5800# bootoctlinux mem=0 numcores=1 > argv[2]: numcores=1 > ELF file is 64 bit > Error allocating memory for elf image! > ## Loading Linux kernel with entry point: 0x20000000 ... > Bootloader: Done loading app on coremask: 0x1 > > From owner-freebsd-mips@FreeBSD.ORG Thu Jan 28 15:23:17 2010 Return-Path: Delivered-To: freebsd-mips@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B8B00106568B for ; Thu, 28 Jan 2010 15:23:17 +0000 (UTC) (envelope-from mahan@mahan.org) Received: from ns.mahan.org (ns.mahan.org [67.116.10.138]) by mx1.freebsd.org (Postfix) with ESMTP id 82B748FC22 for ; Thu, 28 Jan 2010 15:23:17 +0000 (UTC) Received: from Gypsy.mahan.org (crowTrobot [67.116.10.140]) by ns.mahan.org (8.13.6/8.13.6) with ESMTP id o0SFO7pw073359 for ; Thu, 28 Jan 2010 07:24:07 -0800 (PST) (envelope-from mahan@mahan.org) Message-ID: <4B61ABE0.3040903@mahan.org> Date: Thu, 28 Jan 2010 07:23:12 -0800 From: Patrick Mahan User-Agent: Thunderbird 2.0.0.22 (X11/20090605) MIME-Version: 1.0 To: freebsd-mips@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Accessing the latest MIPS sources X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jan 2010 15:23:17 -0000 All, Since I am not a contributor currently to this project, I would like to know how to get a copy of the current sources. I also have access to a CN58XX eval board that is booting our own port of FreeBSD. I've been comparing it to what you folks have done and I have a few tweaks I would like to pass on - some additional Octeon macros, a fix to rgmii so the media info is passed back, stuff like that... I am hoping to convince my bosses to release other stuff as time goes on. Thanks, Patrick From owner-freebsd-mips@FreeBSD.ORG Thu Jan 28 15:28:36 2010 Return-Path: Delivered-To: freebsd-mips@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 88168106566B for ; Thu, 28 Jan 2010 15:28:36 +0000 (UTC) (envelope-from alancyang@gmail.com) Received: from mail-px0-f183.google.com (mail-px0-f183.google.com [209.85.216.183]) by mx1.freebsd.org (Postfix) with ESMTP id 5CC778FC1F for ; Thu, 28 Jan 2010 15:28:36 +0000 (UTC) Received: by pxi13 with SMTP id 13so572655pxi.3 for ; Thu, 28 Jan 2010 07:28:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=gsYtz6DOa2ypx9+pLfo2E9zfEhnZkuDQegGrvzbRTTc=; b=YUl+9SslePJ9MxIwpCaWO8kjirGZcGI4GtbezuOfzCf2vEXA+Yi3y3GjW/NZiucH2p +N7igy4WYS1YCu9/P6AM7eaFHcqpxH9UUnn7GjLSK4hE7Wkh/pa+EBTw1alZUdpcUzzM r3Tl8sIFJE0n0RfxKHtYi9JB+6kPsG2yIVv8U= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=cxAtOMNTFmIzPm3Cw/+x0rNFsSewI8ccL4rzfqrvs4e+DHRYjooKshq7/vd0x+jxLM AVIhep+oSBHHNipUoa4wM27IKlwa9kTnH8PiitgNULlV8Ydl4Z31bcTTtP008BQvoJ8s nw22yuzk+9gF1a/doN8RQj/JFSNmG4yREUs6I= MIME-Version: 1.0 Received: by 10.115.64.6 with SMTP id r6mr2188486wak.85.1264692515881; Thu, 28 Jan 2010 07:28:35 -0800 (PST) In-Reply-To: <4B61AABC.1070404@mahan.org> References: <290865fd1001051526i73dd96d7x18a7a842b903b61d@mail.gmail.com> <4B4433ED.10103@mahan.org> <290865fd1001211445n1b469e11o2f37598c989dbaf7@mail.gmail.com> <20100121.163312.886429907199307448.imp@bsdimp.com> <290865fd1001252225pfc56fd8y53db1865d8512080@mail.gmail.com> <4B61AABC.1070404@mahan.org> Date: Thu, 28 Jan 2010 07:28:34 -0800 Message-ID: <290865fd1001280728x2e899f41j9d66d3e3e367d4d@mail.gmail.com> From: alan yang To: Patrick Mahan Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-mips@freebsd.org Subject: Re: Cavium port X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jan 2010 15:28:36 -0000 i build 32-bit kernel, seems to be loaded ok now. but kernel crashed. wonder people would have idea how to move forward. thanks in advance. --- loadaddr=0x20000000 numcores=16 stdin=serial stdout=serial stderr=serial Environment size: 562/8188 bytes Octeon ebt5800# fatload ide 0 20000000 kernel reading kernel 3236098 bytes read Octeon ebt5800# bootoctlinux 20000000 numcores=1 argv[2]: numcores=1 ELF file is 32 bit Skipping non LOAD program header (type 0x6) Skipping non LOAD program header (type 0x3) Skipping non LOAD program header (type 0x70000000) Allocated memory for ELF segment: addr: 0x1000000, size 0x28c0c0 Loading .text @ 0x810000d4 (2031404 bytes) Loading .MIPS.stubs @ 0x811f0000 (16 bytes) Loading .rodata @ 0x811f2000 (33024 bytes) Loading .reginfo @ 0x811fa100 (24 bytes) Loading .rodata.str1.4 @ 0x811fa118 (190572 bytes) Loading set_sysctl_set @ 0x81228984 (3484 bytes) Loading set_sysinit_set @ 0x81229720 (1664 bytes) Loading set_sysuninit_set @ 0x81229da0 (940 bytes) Loading .interp @ 0x8122a14c (13 bytes) Loading .dynsym @ 0x8122a15c (77824 bytes) Loading .dynstr @ 0x8123d15c (71576 bytes) Loading .hash @ 0x8124e8f4 (35860 bytes) Loading set_kdb_dbbe_set @ 0x81257508 (8 bytes) Loading set_modmetadata_set @ 0x81257510 (288 bytes) Loading set_cons_set @ 0x81257630 (8 bytes) Loading .data @ 0x81257638 (109576 bytes) Loading set_pcpu @ 0x81272240 (3136 bytes) Loading .got @ 0x81272e80 (5272 bytes) Loading .rld_map @ 0x81274318 (4 bytes) Loading .sdata @ 0x8127431c (4 bytes) Clearing .bss @ 0x81274320 (97696 bytes) ## Loading Linux kernel with entry point: 0x810000e0 ... Bootloader: Done loading app on coremask: 0x1 Platform Starting From owner-freebsd-mips@FreeBSD.ORG Thu Jan 28 16:22:10 2010 Return-Path: Delivered-To: freebsd-mips@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B0355106566B for ; Thu, 28 Jan 2010 16:22:10 +0000 (UTC) (envelope-from rrs@lakerest.net) Received: from lakerest.net (unknown [IPv6:2001:240:585:2:213:d4ff:fef3:2d8d]) by mx1.freebsd.org (Postfix) with ESMTP id 63FCB8FC1B for ; Thu, 28 Jan 2010 16:22:10 +0000 (UTC) Received: from [192.168.2.175] (pool-96-249-204-75.snfcca.dsl-w.verizon.net [96.249.204.75]) (authenticated bits=0) by lakerest.net (8.14.3/8.14.3) with ESMTP id o0SGM6CZ070515 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 28 Jan 2010 11:22:08 -0500 (EST) (envelope-from rrs@lakerest.net) Message-Id: From: Randall Stewart To: Patrick Mahan In-Reply-To: <4B61ABE0.3040903@mahan.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 28 Jan 2010 08:22:01 -0800 References: <4B61ABE0.3040903@mahan.org> X-Mailer: Apple Mail (2.936) Cc: freebsd-mips@freebsd.org Subject: Re: Accessing the latest MIPS sources X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jan 2010 16:22:10 -0000 Patrick: All you should have to do is checkout head.. you can use: svn checkout svn://svn.freebsd.org/base/head /usr/your/place/for/head And that should pull it out for you R On Jan 28, 2010, at 7:23 AM, Patrick Mahan wrote: > All, > > Since I am not a contributor currently to this project, I would like > to know how to get a copy of the current sources. I also have access > to a CN58XX eval board that is booting our own port of FreeBSD. I've > been comparing it to what you folks have done and I have a few tweaks > I would like to pass on - some additional Octeon macros, a fix to > rgmii > so the media info is passed back, stuff like that... > > I am hoping to convince my bosses to release other stuff as time goes > on. > > Thanks, > > Patrick > _______________________________________________ > freebsd-mips@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-mips > To unsubscribe, send any mail to "freebsd-mips- > unsubscribe@freebsd.org" > ------------------------------ Randall Stewart 803-317-4952 (cell) 803-345-0391(direct) From owner-freebsd-mips@FreeBSD.ORG Thu Jan 28 17:23:51 2010 Return-Path: Delivered-To: freebsd-mips@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C2B1B106566B for ; Thu, 28 Jan 2010 17:23:51 +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 875C88FC08 for ; Thu, 28 Jan 2010 17:23:51 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.3/8.14.1) with ESMTP id o0SHJQeu009524; Thu, 28 Jan 2010 10:19:26 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Thu, 28 Jan 2010 10:20:19 -0700 (MST) Message-Id: <20100128.102019.411418020285411003.imp@bsdimp.com> To: mahan@mahan.org From: "M. Warner Losh" In-Reply-To: <4B61ABE0.3040903@mahan.org> References: <4B61ABE0.3040903@mahan.org> X-Mailer: Mew version 6.3 on Emacs 22.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-mips@freebsd.org Subject: Re: Accessing the latest MIPS sources X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jan 2010 17:23:51 -0000 In message: <4B61ABE0.3040903@mahan.org> Patrick Mahan writes: : Since I am not a contributor currently to this project, I would like : to know how to get a copy of the current sources. I also have access : to a CN58XX eval board that is booting our own port of FreeBSD. I've : been comparing it to what you folks have done and I have a few tweaks : I would like to pass on - some additional Octeon macros, a fix to : rgmii so the media info is passed back, stuff like that... That would be awesome. The latest code is available from the tip of FreeBSD's development branch (svn://svn.freebsd.org/base/head). Please feel free to pass any changes you have my way. : I am hoping to convince my bosses to release other stuff as time goes : on. That would rock too. Warner From owner-freebsd-mips@FreeBSD.ORG Thu Jan 28 17:23:54 2010 Return-Path: Delivered-To: freebsd-mips@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 168331065670 for ; Thu, 28 Jan 2010 17:23:54 +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 C9AEE8FC0A for ; Thu, 28 Jan 2010 17:23:53 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.3/8.14.1) with ESMTP id o0SHD3Fs009430; Thu, 28 Jan 2010 10:13:04 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Thu, 28 Jan 2010 10:13:57 -0700 (MST) Message-Id: <20100128.101357.69891821659229949.imp@bsdimp.com> To: alancyang@gmail.com From: "M. Warner Losh" In-Reply-To: <290865fd1001280620p300e318bh848cb801d681ff40@mail.gmail.com> References: <290865fd1001262235m13ec4a2em863da596fd9a6c2@mail.gmail.com> <20100127.090718.131509470573849915.imp@bsdimp.com> <290865fd1001280620p300e318bh848cb801d681ff40@mail.gmail.com> X-Mailer: Mew version 6.3 on Emacs 22.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-mips@freebsd.org Subject: Re: Cavium port X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jan 2010 17:23:54 -0000 In message: <290865fd1001280620p300e318bh848cb801d681ff40@mail.gmail.com> alan yang writes: : For code base that I checked out from svn repo the project/mips branch : on 10/14/2009, would you see problem if i just getting OCTEON1-32 conf : file and build kernel from there, or should I at this time check out : 9-CURRENT for octeon port I am interested in and track / follow that : way. All the changes in projects/mips branch was merged into head a few weeks ago now. If you have an old tree you'd like to update, I'm told that svn switch svn://svn.freebsd.org/base/head would merge the changes between the old mips branch you are on and the current -head. The October 14th code base likely is too old to work properly on real hardware. IIRC, that was about the time I just started to push the cavium octeon support into the projects/mips tree and the work was fairly incomplete at that time. Warner From owner-freebsd-mips@FreeBSD.ORG Thu Jan 28 22:28:24 2010 Return-Path: Delivered-To: freebsd-mips@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A04061065784 for ; Thu, 28 Jan 2010 22:28:24 +0000 (UTC) (envelope-from neelnatu@gmail.com) Received: from mail-px0-f183.google.com (mail-px0-f183.google.com [209.85.216.183]) by mx1.freebsd.org (Postfix) with ESMTP id 787F88FC21 for ; Thu, 28 Jan 2010 22:28:24 +0000 (UTC) Received: by pxi13 with SMTP id 13so878858pxi.3 for ; Thu, 28 Jan 2010 14:28:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=1u4OtgowkhFbl+8+S1yU5civuBQSA/dkrOvp7jAEt3E=; b=SI8uoSb5DaicdPf/WVcc3VJOuSqNnoGrsz7GTYe50J2XVNsdXX4gFR2EYdqJPK7RHd yJycW8i/Zo8qI30F3UvEbZDoVGwK90vWjOskfbkldC883jr72HWIMyUBw1Dl5xlanE2a HdxAHMYf4tEd6GTlU9q+DBlSjmC41M5fvUlSY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=tGTmHHFrMdiwZ1u5tnChchphlzRUbavyacMeU89D7IRRUASjqYF7j2HN9JsGBbHcZB 1kdQ246mRMTp4JPU0iU1IOm/1LK+MLKnh+5+YuESAiBwJ+hR2vgxz4vQNfmP6MUVQSvD mv0r6M+9IMcirAcZDX8TChyjoWUdZPAbJALpI= MIME-Version: 1.0 Received: by 10.142.3.28 with SMTP id 28mr1641614wfc.106.1264716100606; Thu, 28 Jan 2010 14:01:40 -0800 (PST) In-Reply-To: <20100128.132114.1004138037722505681.imp@bsdimp.com> References: <20100128.132114.1004138037722505681.imp@bsdimp.com> Date: Thu, 28 Jan 2010 14:01:40 -0800 Message-ID: From: Neel Natu To: freebsd-mips@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Code review: groundwork for SMP X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jan 2010 22:28:24 -0000 Forwarding to freebsd-mips as suggested by Warner. This is a patch to provide access to pcpu structures for SMP kernels. The basic idea is to use a the same virtual address as a window onto distinct physical memory locations - one per processor. The physical address that you access through this mapping depends on which cpu you are currently executing on. We can now use the virtual address on any processor to access its per-cpu area. The details are: 1. The virtual address for 'struct pcpu *pcpup' is obtained by stealing 2 pages worth of KVA in pmap_bootstrap(). 2. The mapping from the constant virtual address to a distinct physical page is done in cpu_pcpu_init() through a wired TLB entry. 3. A side-effect of this is that we reserve 2 pages worth of memory for the pcpu but in reality it needs much less than that. The unused memory is now used as the boot stack for the BSP and APs. I also cleaned up locore.S to remove the SMP-specific bits from it. I plan to use a separate mpboot.S for the AP bootstrap. Please review. The patch is available here: http://people.freebsd.org/~neel/smp_groundwork.diff best Neel From owner-freebsd-mips@FreeBSD.ORG Fri Jan 29 04:27:07 2010 Return-Path: Delivered-To: freebsd-mips@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D875E1065676 for ; Fri, 29 Jan 2010 04:27:07 +0000 (UTC) (envelope-from rrs@lakerest.net) Received: from lakerest.net (unknown [IPv6:2001:240:585:2:213:d4ff:fef3:2d8d]) by mx1.freebsd.org (Postfix) with ESMTP id 8D2B38FC0C for ; Fri, 29 Jan 2010 04:27:07 +0000 (UTC) Received: from [192.168.2.175] (pool-96-249-204-75.snfcca.dsl-w.verizon.net [96.249.204.75]) (authenticated bits=0) by lakerest.net (8.14.3/8.14.3) with ESMTP id o0T4R2ct099668 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 28 Jan 2010 23:27:04 -0500 (EST) (envelope-from rrs@lakerest.net) Message-Id: <66207A08-F691-4603-A6C5-9C675414C91E@lakerest.net> From: Randall Stewart To: Neel Natu In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 28 Jan 2010 20:26:56 -0800 References: <20100128.132114.1004138037722505681.imp@bsdimp.com> X-Mailer: Apple Mail (2.936) Cc: freebsd-mips@freebsd.org Subject: Re: Code review: groundwork for SMP X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jan 2010 04:27:08 -0000 Neel: Now overall my first reaction to this was.. hey this is a cool way to do this. But I have been thinking about this a bit more and I am now having second thoughts. So lets see the old way was to have an array of pcpup[MAXCPU]. The down side to this is it may cause cache line tweaks and you are limited by the MAXCPU of course. Now we can get around the cache line tweaks by simply padding out the structure to the cache line size.. so thats probably not an issue... The MAXCPU is not extendable without a recompile.. but thats also true for your method. Though sexy it has a very big down side that I think calls for us to think real hard before going this route. It burns up TLB entries. Ok that does not sound so bad on the surface but wait lets think about this.. and I am going to speak in terms of XLR... but other mips processors may have the same issue. 1) I have 8 cores per cpu pack. 2) Each core has 4 "threads" which are kinda hyper threads, their own register set, there own everything accept they share a pipeline and get scheduled when one of the others are blocked. 3) This means I still need a pcpup per thread. 4) Now I have 64 TLB entries for every CPU complex. I can have them 16 per thread OR 64 shared amongst all threads. 5) This means I dedicate 4 of my 64 TLB entries for your pcpup entries. Now if I am busy, when I need TLB entries most, I am pretty sure all 4 of those pcpup entries will need to be active and can't be pulled out. So I have lost over 6% of my TLB entries for this method. a) I am still bound to MAXCPU .. so there is no dynamics here.. not that there needs to be b) I loose one of the most precious and sparse resources in a mips processor. c) And I really don't gain much over just having an array of pcpup structures indexed by my CPUID separated by a pad of a cache line each. I really would vote that we DO NOT do this. Instead lets stick with an array and pad it up to a cache line size if its not already.. Other wise you burn up 4 entries for me (and maybe other platforms) and get very little gain. I would rather find a way to get a superpage mapped for the entire kernel + some and hardwire it in... I am not trying to be negative here because I do think its a real sexy way to access the pcpups.. it makes it real transparent... and on the XLP where I would have a lot more TLB entries thats cool.. but I have to think of the existing hardware and its very very small TLB's which is one of the main things limiting performance. So overall I say we do NOT do this.. R On Jan 28, 2010, at 2:01 PM, Neel Natu wrote: > Forwarding to freebsd-mips as suggested by Warner. > > This is a patch to provide access to pcpu structures for SMP kernels. > > The basic idea is to use a the same virtual address as a window onto > distinct physical memory locations - one per processor. The physical > address that you access through this mapping depends on which cpu you > are currently executing on. We can now use the virtual address on any > processor to access its per-cpu area. > > The details are: > > 1. The virtual address for 'struct pcpu *pcpup' is obtained by > stealing 2 pages worth of KVA in pmap_bootstrap(). > > 2. The mapping from the constant virtual address to a distinct > physical page is done in cpu_pcpu_init() through a wired TLB entry. > > 3. A side-effect of this is that we reserve 2 pages worth of memory > for the pcpu but in reality it needs much less than that. The unused > memory is now used as the boot stack for the BSP and APs. > > I also cleaned up locore.S to remove the SMP-specific bits from it. I > plan to use a separate mpboot.S for the AP bootstrap. > > Please review. > > The patch is available here: > http://people.freebsd.org/~neel/smp_groundwork.diff > > best > Neel > _______________________________________________ > freebsd-mips@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-mips > To unsubscribe, send any mail to "freebsd-mips- > unsubscribe@freebsd.org" > ------------------------------ Randall Stewart 803-317-4952 (cell) 803-345-0391(direct) From owner-freebsd-mips@FreeBSD.ORG Fri Jan 29 05:07:53 2010 Return-Path: Delivered-To: freebsd-mips@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 072C21065670 for ; Fri, 29 Jan 2010 05:07:53 +0000 (UTC) (envelope-from juli@clockworksquid.com) Received: from mail-pz0-f176.google.com (mail-pz0-f176.google.com [209.85.222.176]) by mx1.freebsd.org (Postfix) with ESMTP id DAE518FC12 for ; Fri, 29 Jan 2010 05:07:52 +0000 (UTC) Received: by pzk6 with SMTP id 6so1109810pzk.3 for ; Thu, 28 Jan 2010 21:07:52 -0800 (PST) MIME-Version: 1.0 Sender: juli@clockworksquid.com Received: by 10.142.117.1 with SMTP id p1mr230919wfc.185.1264740052089; Thu, 28 Jan 2010 20:40:52 -0800 (PST) In-Reply-To: <66207A08-F691-4603-A6C5-9C675414C91E@lakerest.net> References: <20100128.132114.1004138037722505681.imp@bsdimp.com> <66207A08-F691-4603-A6C5-9C675414C91E@lakerest.net> From: Juli Mallett Date: Thu, 28 Jan 2010 20:40:32 -0800 X-Google-Sender-Auth: 04ed61989917d238 Message-ID: To: Randall Stewart Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: freebsd-mips@freebsd.org, Neel Natu Subject: Re: Code review: groundwork for SMP X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jan 2010 05:07:53 -0000 On Thu, Jan 28, 2010 at 20:26, Randall Stewart wrote: > It burns up TLB entries. Ok that does not sound so bad on the > surface but wait lets think about this.. and I am going to > speak in terms of XLR... but other mips processors may have > the same issue. > > 1) I have 8 cores per cpu pack. > 2) Each core has 4 "threads" which are kinda hyper threads, their > own register set, there own everything accept they share a pipeline > and get scheduled when one of the others are blocked. > 3) This means I still need a pcpup per thread. > 4) Now I have 64 TLB entries for every CPU complex. I can have them > 16 per thread OR 64 shared amongst all threads. > 5) This means I dedicate 4 of my 64 TLB entries for your pcpup entries. So on your systems threads share the TLB? Wired TLB entries can't be pulled out (in the case of the kernel stack it's basically catastrophic for that to happen.) A compromise if your TLB entries are really at a premium is to use a single large entry (using, say, a single 32k page) that contains both PCPU and the kernel stack, or a page which has pointers to pcpu data, the kernel stack, etc. I seem to recall seeing a port of FreeBSD that used the same storage for the kernel stack and PCPU data, but I could be mistaken. There are other trade-offs available, of course. If we don't use the gp for accessing small data, we can keep a pointer to the pcpu data of a CPU in gp whenever the kernel is running, and then PCPU accesses are just a madder of loading from offset+gp, which is very quick =97 faster than the wired TLB entry mechanism, unless you use a virtual address for the pcpu in which case it can be painful. As there are more things like VIMAGE, the amount of small global data in the kernel is going to fall and making gp a pcpu pointer makes more sense. My old port used -G0 and I still disable use of the gp in my non-FreeBSD MIPS work =97 I think NetBSD used to but I haven't noticed what FreeBSD does. More curiosity than anything (since I don't seem to be able to get an RMI system to develop on): if the threads are sharing the TLB, how are updates to TLB-related fields synchronized? How do you atomically increase the wired count of the TLB? How does 'tlbwr' work? Do you have to use special instructions when you're sharing the TLB that are XLR-specific? Juli. From owner-freebsd-mips@FreeBSD.ORG Fri Jan 29 05:29:01 2010 Return-Path: Delivered-To: freebsd-mips@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5EE8E106566C; Fri, 29 Jan 2010 05:29:01 +0000 (UTC) (envelope-from rrs@lakerest.net) Received: from lakerest.net (unknown [IPv6:2001:240:585:2:213:d4ff:fef3:2d8d]) by mx1.freebsd.org (Postfix) with ESMTP id F0B4E8FC1A; Fri, 29 Jan 2010 05:29:00 +0000 (UTC) Received: from [192.168.2.175] (pool-96-249-204-75.snfcca.dsl-w.verizon.net [96.249.204.75]) (authenticated bits=0) by lakerest.net (8.14.3/8.14.3) with ESMTP id o0T5Svfd002324 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 29 Jan 2010 00:28:59 -0500 (EST) (envelope-from rrs@lakerest.net) Message-Id: <85D9D383-29A3-4F09-A2FE-61E4EA85CE9B@lakerest.net> From: Randall Stewart To: Juli Mallett In-Reply-To: Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 28 Jan 2010 21:28:51 -0800 References: <20100128.132114.1004138037722505681.imp@bsdimp.com> <66207A08-F691-4603-A6C5-9C675414C91E@lakerest.net> X-Mailer: Apple Mail (2.936) Cc: freebsd-mips@FreeBSD.org, Neel Natu Subject: Re: Code review: groundwork for SMP X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jan 2010 05:29:01 -0000 On Jan 28, 2010, at 8:40 PM, Juli Mallett wrote: > On Thu, Jan 28, 2010 at 20:26, Randall Stewart =20 > wrote: >> It burns up TLB entries. Ok that does not sound so bad on the >> surface but wait lets think about this.. and I am going to >> speak in terms of XLR... but other mips processors may have >> the same issue. >> >> 1) I have 8 cores per cpu pack. >> 2) Each core has 4 "threads" which are kinda hyper threads, their >> own register set, there own everything accept they share a pipeline >> and get scheduled when one of the others are blocked. >> 3) This means I still need a pcpup per thread. >> 4) Now I have 64 TLB entries for every CPU complex. I can have them >> 16 per thread OR 64 shared amongst all threads. >> 5) This means I dedicate 4 of my 64 TLB entries for your pcpup =20 >> entries. > > So on your systems threads share the TLB? Wired TLB entries can't be > pulled out (in the case of the kernel stack it's basically > catastrophic for that to happen.) A compromise if your TLB entries > are really at a premium is to use a single large entry (using, say, a > single 32k page) that contains both PCPU and the kernel stack, or a > page which has pointers to pcpu data, the kernel stack, etc. I seem > to recall seeing a port of FreeBSD that used the same storage for the > kernel stack and PCPU data, but I could be mistaken. Which means you have a big array that you are offsetting. I was even thinking get a LARGE entry.. one that is say 8 Meg for the kernel.. covering all text/data etc... with this new super page stuff. of course I have never looked into how its implemented.. Going back to your idea. is that not the same thing as having an index into an array. Yes, you pay an index reference for every access .. or at least one to setup a pointer.. but I think that it much cheaper than a TLB miss is... (words for imp to think about)... > > There are other trade-offs available, of course. If we don't use the > gp for accessing small data, we can keep a pointer to the pcpu data of > a CPU in gp whenever the kernel is running, and then PCPU accesses are > just a madder of loading from offset+gp, which is very quick =97 = faster > than the wired TLB entry mechanism, unless you use a virtual address > for the pcpu in which case it can be painful. As there are more > things like VIMAGE, the amount of small global data in the kernel is > going to fall and making gp a pcpu pointer makes more sense. My old > port used -G0 and I still disable use of the gp in my non-FreeBSD MIPS > work =97 I think NetBSD used to but I haven't noticed what FreeBSD = does. > This is an interesting idea... need to think about it more ;-) > More curiosity than anything (since I don't seem to be able to get an > RMI system to develop on): if the threads are sharing the TLB, how are > updates to TLB-related fields synchronized? How do you atomically > increase the wired count of the TLB? How does 'tlbwr' work? Do you > have to use special instructions when you're sharing the TLB that are > XLR-specific? I can't tell you how the hardware works.. I can either have the TLB divided into 16 entries per thread OR enable a special global register and get 64 entries that all threads see. In any case I just don't see that this has that much gain... its sexy.. but I think its a tradeoff like everything.. R > > Juli. > ------------------------------ Randall Stewart 803-317-4952 (cell) 803-345-0391(direct) From owner-freebsd-mips@FreeBSD.ORG Fri Jan 29 05:47:14 2010 Return-Path: Delivered-To: freebsd-mips@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E4020106566B; Fri, 29 Jan 2010 05:47:13 +0000 (UTC) (envelope-from rrs@lakerest.net) Received: from lakerest.net (unknown [IPv6:2001:240:585:2:213:d4ff:fef3:2d8d]) by mx1.freebsd.org (Postfix) with ESMTP id 990858FC13; Fri, 29 Jan 2010 05:47:13 +0000 (UTC) Received: from [192.168.2.175] (pool-96-249-204-75.snfcca.dsl-w.verizon.net [96.249.204.75]) (authenticated bits=0) by lakerest.net (8.14.3/8.14.3) with ESMTP id o0T5l9Ow003009 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 29 Jan 2010 00:47:12 -0500 (EST) (envelope-from rrs@lakerest.net) Message-Id: <37F434F8-C845-4A20-8188-CA26FB7B8C5C@lakerest.net> From: Randall Stewart To: "C. Jayachandran" In-Reply-To: <98a59be81001282130n1776b31bn3f6995b6ef136ff0@mail.gmail.com> Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 28 Jan 2010 21:47:04 -0800 References: <20100128.132114.1004138037722505681.imp@bsdimp.com> <66207A08-F691-4603-A6C5-9C675414C91E@lakerest.net> <98a59be81001282130n1776b31bn3f6995b6ef136ff0@mail.gmail.com> X-Mailer: Apple Mail (2.936) Cc: freebsd-mips@freebsd.org, Neel Natu Subject: Re: Code review: groundwork for SMP X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jan 2010 05:47:14 -0000 comments in-line.. On Jan 28, 2010, at 9:30 PM, C. Jayachandran wrote: > I'm new to this list, joined yesterday. I work at RMI (now Netlogic), > and did part of our internal port of FreeBSD 6.4 to XLR/XLS > processors. > >> So on your systems threads share the TLB? Wired TLB entries can't be >> pulled out (in the case of the kernel stack it's basically >> catastrophic for that to happen.) A compromise if your TLB entries >> are really at a premium is to use a single large entry (using, say, a >> single 32k page) that contains both PCPU and the kernel stack, or a >> page which has pointers to pcpu data, the kernel stack, etc. I seem >> to recall seeing a port of FreeBSD that used the same storage for the >> kernel stack and PCPU data, but I could be mistaken. > > Our cpus can be configured in a way that they share the 64 TLB entries > among the 4 threads in the core. You could also configure the threads > so that they have 16 independent entires each. But 16 is too less for > running FreeBSD, so by default we used the shared TLB mode. > >> There are other trade-offs available, of course. If we don't use the >> gp for accessing small data, we can keep a pointer to the pcpu data =20= >> of >> a CPU in gp whenever the kernel is running, and then PCPU accesses =20= >> are >> just a madder of loading from offset+gp, which is very quick =97 = faster >> than the wired TLB entry mechanism, unless you use a virtual address >> for the pcpu in which case it can be painful. As there are more >> things like VIMAGE, the amount of small global data in the kernel is >> going to fall and making gp a pcpu pointer makes more sense. My old >> port used -G0 and I still disable use of the gp in my non-FreeBSD =20 >> MIPS >> work =97 I think NetBSD used to but I haven't noticed what FreeBSD =20= >> does. > > Again on XLR processors, there are per-thread scratch registers in > COP0. So our preferred way of doing this was to have the per-cpu > pointer in one of these scratch registers. We can also get the TLB > out of the way for some of these by reserving KSEG0 region on startup > for these and for stack. Hmm I wonder if other processors as well have a per-cpu scratch register we can use. This might be an easy way forward. You load the scratch reg with the pcpup (I remember seeing that in the 6.x port of yours) and then reference that whenever you want to use it. Do all of the mips processors have this scratch registers (I guess I should scope that.. do the ones we care about have a scratch register).. or is this an optional feature. Another question is what is the cost cycle wise of accessing this register.. Far better I am sure than a TLB miss in user space due to lack of TLB entries... But I wonder how it compares to a indexed access that doing a pcpup =3D &pcpu[getcpuid()]; would cost.. R > > I agree with Randall here, the preferred way is to avoid wiring the > TLB entries. Can't we reserve some area for this at start-up and keep > the pointer in a platform-specific macro? > >> More curiosity than anything (since I don't seem to be able to get an >> RMI system to develop on): if the threads are sharing the TLB, how =20= >> are >> updates to TLB-related fields synchronized? How do you atomically >> increase the wired count of the TLB? How does 'tlbwr' work? Do you >> have to use special instructions when you're sharing the TLB that are >> XLR-specific? > > Each thread has its own COP0 registers, but they update the core's > TLB, so there are no special TLB instructions. > > Regards, > JC. > > -- > C. Jayachandran c.jayachandran@gmail.com > ------------------------------ Randall Stewart 803-317-4952 (cell) 803-345-0391(direct) From owner-freebsd-mips@FreeBSD.ORG Fri Jan 29 05:57:37 2010 Return-Path: Delivered-To: freebsd-mips@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8B326106566B for ; Fri, 29 Jan 2010 05:57:36 +0000 (UTC) (envelope-from c.jayachandran@gmail.com) Received: from mail-px0-f183.google.com (mail-px0-f183.google.com [209.85.216.183]) by mx1.freebsd.org (Postfix) with ESMTP id 5CA548FC17 for ; Fri, 29 Jan 2010 05:57:36 +0000 (UTC) Received: by pxi13 with SMTP id 13so1147928pxi.3 for ; Thu, 28 Jan 2010 21:57:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=h/YoQw8brMRw+qug79xUFmsfSbeAyQvjq4C/WZh2oDM=; b=h4cXTZZawo19zbdLvY225qS/pYbWBbwwJjhE+cfgFHB/376oIqj5SS2yC5m2xMbQXe 9w97eZF2vuwzc5I41+yRRNfH2m77Dot1JiccRUlpHXoE6PlrLgCTJy6zWHaHtM5OuEo3 CLqmp2Oe9wnUJg9f3p9q2p7zgdYjYjVqOY74o= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=r38e+bdR8NC1i0zauqvb5w/X99iP4iecnAA5bdSKXcuLLBWUzyDtmxAQcX71z0zDb2 YLeoIuszxB9FFVsUN15v5mfnaHQKeduEuZSjwwoh6wrEknlIAn3WfgwE6ePNdHmJrXuw sQeadtiqG+Jd+iRbDD8CB6sgqRO0aALETi9v0= MIME-Version: 1.0 Received: by 10.141.15.9 with SMTP id s9mr244458rvi.221.1264743041603; Thu, 28 Jan 2010 21:30:41 -0800 (PST) In-Reply-To: References: <20100128.132114.1004138037722505681.imp@bsdimp.com> <66207A08-F691-4603-A6C5-9C675414C91E@lakerest.net> Date: Fri, 29 Jan 2010 11:00:41 +0530 Message-ID: <98a59be81001282130n1776b31bn3f6995b6ef136ff0@mail.gmail.com> From: "C. Jayachandran" To: Juli Mallett Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-mips@freebsd.org, Neel Natu Subject: Re: Code review: groundwork for SMP X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jan 2010 05:57:37 -0000 I'm new to this list, joined yesterday.=C2=A0 I work at RMI (now Netlogic), and did part of our internal port of FreeBSD 6.4 to XLR/XLS processors. > So on your systems threads share the TLB? =C2=A0Wired TLB entries can't b= e > pulled out (in the case of the kernel stack it's basically > catastrophic for that to happen.) =C2=A0A compromise if your TLB entries > are really at a premium is to use a single large entry (using, say, a > single 32k page) that contains both PCPU and the kernel stack, or a > page which has pointers to pcpu data, the kernel stack, etc. =C2=A0I seem > to recall seeing a port of FreeBSD that used the same storage for the > kernel stack and PCPU data, but I could be mistaken. Our cpus can be configured in a way that they share the 64 TLB entries among the 4 threads in the core. You could also configure the threads so that they have 16 independent entires each. But 16 is too less for running FreeBSD, so by default we used the shared TLB mode. > There are other trade-offs available, of course. =C2=A0If we don't use th= e > gp for accessing small data, we can keep a pointer to the pcpu data of > a CPU in gp whenever the kernel is running, and then PCPU accesses are > just a madder of loading from offset+gp, which is very quick =E2=80=94 fa= ster > than the wired TLB entry mechanism, unless you use a virtual address > for the pcpu in which case it can be painful. =C2=A0As there are more > things like VIMAGE, the amount of small global data in the kernel is > going to fall and making gp a pcpu pointer makes more sense. =C2=A0My old > port used -G0 and I still disable use of the gp in my non-FreeBSD MIPS > work =E2=80=94 I think NetBSD used to but I haven't noticed what FreeBSD = does. Again on XLR processors, there are per-thread scratch registers in COP0. So our preferred way of doing this was to have the per-cpu pointer in one of these scratch registers. We can also get the TLB out of the way for some of these by reserving KSEG0 region on startup for these and for stack. I agree with Randall here, the preferred way is to avoid wiring the TLB entries. Can't we reserve some area for this at start-up and keep the pointer in a platform-specific macro? > More curiosity than anything (since I don't seem to be able to get an > RMI system to develop on): if the threads are sharing the TLB, how are > updates to TLB-related fields synchronized? =C2=A0How do you atomically > increase the wired count of the TLB? =C2=A0How does 'tlbwr' work? =C2=A0D= o you > have to use special instructions when you're sharing the TLB that are > XLR-specific? Each thread has its own COP0 registers, but they update the core's TLB, so there are no special TLB instructions. Regards, JC. -- C. Jayachandran =C2=A0 =C2=A0c.jayachandran@gmail.com From owner-freebsd-mips@FreeBSD.ORG Fri Jan 29 06:31:02 2010 Return-Path: Delivered-To: freebsd-mips@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BCEA0106566B for ; Fri, 29 Jan 2010 06:31:02 +0000 (UTC) (envelope-from juli@clockworksquid.com) Received: from mail-px0-f183.google.com (mail-px0-f183.google.com [209.85.216.183]) by mx1.freebsd.org (Postfix) with ESMTP id 99C908FC0A for ; Fri, 29 Jan 2010 06:31:02 +0000 (UTC) Received: by pxi13 with SMTP id 13so1167413pxi.3 for ; Thu, 28 Jan 2010 22:31:02 -0800 (PST) MIME-Version: 1.0 Sender: juli@clockworksquid.com Received: by 10.142.9.27 with SMTP id 27mr296254wfi.241.1264746662101; Thu, 28 Jan 2010 22:31:02 -0800 (PST) In-Reply-To: <37F434F8-C845-4A20-8188-CA26FB7B8C5C@lakerest.net> References: <20100128.132114.1004138037722505681.imp@bsdimp.com> <66207A08-F691-4603-A6C5-9C675414C91E@lakerest.net> <98a59be81001282130n1776b31bn3f6995b6ef136ff0@mail.gmail.com> <37F434F8-C845-4A20-8188-CA26FB7B8C5C@lakerest.net> From: Juli Mallett Date: Thu, 28 Jan 2010 22:30:42 -0800 X-Google-Sender-Auth: 402c6c7f69579d0a Message-ID: To: Randall Stewart Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-mips@freebsd.org, Neel Natu Subject: Re: Code review: groundwork for SMP X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jan 2010 06:31:02 -0000 On Thu, Jan 28, 2010 at 21:47, Randall Stewart wrote: > Do all of the mips processors have this scratch registers (I guess > I should scope that.. do the ones we care about have a scratch > register).. or is this an optional feature. Not anything like all or even all interesting ones. There are some registers you could try abusing that are widely-available but mostly unused, but most of them would require such a degree of discipline that they're not worth it. (Hell, you could use badvaddr as long as you refreshed it after every TLB miss.) > But I wonder how it compares to a indexed access that doing a > > pcpup = &pcpu[getcpuid()]; The problem is get "getcpuid" is very slow on some systems. If you have a really quick way of getting it, this isn't too bad, but my understanding is that that's one of the key reasons to avoid the array approach. Juli. From owner-freebsd-mips@FreeBSD.ORG Fri Jan 29 06:42:39 2010 Return-Path: Delivered-To: freebsd-mips@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7F7AE106566B for ; Fri, 29 Jan 2010 06:42:39 +0000 (UTC) (envelope-from juli@clockworksquid.com) Received: from mail-px0-f183.google.com (mail-px0-f183.google.com [209.85.216.183]) by mx1.freebsd.org (Postfix) with ESMTP id 5CE5B8FC12 for ; Fri, 29 Jan 2010 06:42:39 +0000 (UTC) Received: by pxi13 with SMTP id 13so1174302pxi.3 for ; Thu, 28 Jan 2010 22:42:39 -0800 (PST) MIME-Version: 1.0 Sender: juli@clockworksquid.com Received: by 10.142.3.25 with SMTP id 25mr312416wfc.200.1264747359071; Thu, 28 Jan 2010 22:42:39 -0800 (PST) In-Reply-To: <85D9D383-29A3-4F09-A2FE-61E4EA85CE9B@lakerest.net> References: <20100128.132114.1004138037722505681.imp@bsdimp.com> <66207A08-F691-4603-A6C5-9C675414C91E@lakerest.net> <85D9D383-29A3-4F09-A2FE-61E4EA85CE9B@lakerest.net> From: Juli Mallett Date: Thu, 28 Jan 2010 22:42:19 -0800 X-Google-Sender-Auth: 0664fad28df8094f Message-ID: To: Randall Stewart Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: freebsd-mips@freebsd.org, Neel Natu Subject: Re: Code review: groundwork for SMP X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jan 2010 06:42:39 -0000 On Thu, Jan 28, 2010 at 21:28, Randall Stewart wrote: >> [ Using a single wired TLB entry for kstack and pcpu ] > > Which means you have a big array that you are offsetting. Not really =97 you can have a structure at 0xc000000000000000u (or the same >> 32) with two pointers in it, even, one to pcpu and one to KSTACK_PAGES direct-mapped, contiguous pages. Then you can load the kstack address or the pcpu base very quickly. Of course, you can even have a single wired entry consisting of the pcpu data and then put a pointer to the top of the kstack in it. I don't think you can get by with no wired TLB entries, but you also don't have to index a big array. The nice thing about setting up a per-CPU TLB entry (you have to set up at least one, the kstack, in order to be able to handle exceptions) is that then you need only access offsets into it that are known at compile time and constant no matter what CPU you're running on. Load the kstack by doing "ld sp, 0(0xc...)" and load the pcpu address by doing "ld t0, 8(0xc....)". Two wired entries lets you get rid of the indirection, but you can get by with one and still not have to do (1) run-time computation of the index into some array (2) possibly very expensive getting of the cpuid. > I was even thinking get a LARGE entry.. one that is say 8 Meg > for the kernel.. covering all text/data etc... with this > new super page stuff. of course I have never looked into how > its implemented.. That would be easy to do, but what would be the benefits of accessing that data through a wired TLB entry instead of the direct map? > Yes, you pay an index reference for every access .. or at > least one to setup a pointer.. but I think that it much cheaper > than a TLB miss is... (words for imp to think about)... Yes, TLB misses are very slow. Your desire to avoid adding another wired entry seems pretty reasonable. I think that using a single wired TLB entry for a mux or for both the kstack and pcpu is easy and usable. I feel like just wiring the kstack and putting a direct-mapped, sometimes-recomputed pointer to the pcpu into gp is the best combination in the long run =97 even just loading an immediate 64-bit address is pretty slow wrt how often things in the PCPU are accessed in SMP kernels. Juli. From owner-freebsd-mips@FreeBSD.ORG Fri Jan 29 15:25:32 2010 Return-Path: Delivered-To: freebsd-mips@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F41FE106568F; Fri, 29 Jan 2010 15:25:31 +0000 (UTC) (envelope-from neelnatu@gmail.com) Received: from mail-pz0-f176.google.com (mail-pz0-f176.google.com [209.85.222.176]) by mx1.freebsd.org (Postfix) with ESMTP id BFBDD8FC14; Fri, 29 Jan 2010 15:25:31 +0000 (UTC) Received: by pzk6 with SMTP id 6so1479240pzk.3 for ; Fri, 29 Jan 2010 07:25:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=OwDCdBXA+t7BQVc4klNV7ZpyWZx8jOqlZxWW0qXg9pw=; b=EuSxlypaYJI6Sh6DmmFokPmOa8tcLoQ657nVokMBHGFxlxN7hYD4WlrJfkcgT4MtVx x0ZrtoMR5qbR6KqgwH573RBkK+QvI4zM4KILQOAGi3WT2zgW0P3QOaNvTAsIkcuxd51N FU/r6SCVEK5opzWAWjAe3Mbu2TSSEE+NeWE4c= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=VAE4fVVv2wGJqwAmS0ItdjgOHTYylNkafdaxLHj0vl00nDR/095bQ1O0RFNBAISU1R da45qO+BRicUKtaciFVjhkMqRxcsw9fpeAUJEvlsRwNSeiUoUa4a0PiT7Lu50nBl9oWL 0P29gs7FFcVT9Zc1NejHlrONO8W3bfjjf+bn0= MIME-Version: 1.0 Received: by 10.142.56.12 with SMTP id e12mr603690wfa.332.1264778731105; Fri, 29 Jan 2010 07:25:31 -0800 (PST) In-Reply-To: References: <20100128.132114.1004138037722505681.imp@bsdimp.com> <66207A08-F691-4603-A6C5-9C675414C91E@lakerest.net> <85D9D383-29A3-4F09-A2FE-61E4EA85CE9B@lakerest.net> Date: Fri, 29 Jan 2010 07:25:31 -0800 Message-ID: From: Neel Natu To: Juli Mallett Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: freebsd-mips@freebsd.org Subject: Re: Code review: groundwork for SMP X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jan 2010 15:25:32 -0000 Thanks Juli, Randall and JC for the comments. I think it is fair to ask that we don't burn another TLB entry to store the pcpu data. So maybe it might help if I went through what options I considered before settling on this one: - One of the first things that I did investigate was using per-cpu scratch registers but the Sibyte did not have any and they are not part of the MIPS architecture. - The second thing I considered was using a platform-specific getcpuid() to index into the struct pcpu pcpu[MAXCPU] array to compute the KSEG0 address of pcpu at runtime. However this turned out to be a bit messy because there are consumers of getcpuid() in exception context where we are restricted to using only k0 and k1 (and sometimes only one of them). Also, like Juli pointed out getcpuid() is slow on some cpus and I did not want to make the assumption that one could write getcpuid() using a single k0/k1 register. So, having the pcpu pointer in a TLB entry divorces us from any assumptions about the CPU we are running on. I think that there is a legitimate concern about this on the XLR - but given that you are sharing the TLB among 4 threads I think there is the bigger issue of the wired kstack entries that you need to solve before even thinking about pcpu mapping. I did not consider the approach suggested by Juli where the pcpu and kstack pointers can be stashed in a single wired TLB entry. I need some time to chew on it and prototype it. I would still like to commit this so as to keep making progress on the SMP support. This is a small piece of the bigger goal of getting SMP functional and can be replaced in the future if need be. best Neel On Thu, Jan 28, 2010 at 10:42 PM, Juli Mallett wrote= : > On Thu, Jan 28, 2010 at 21:28, Randall Stewart wrote: >>> [ Using a single wired TLB entry for kstack and pcpu ] >> >> Which means you have a big array that you are offsetting. > > Not really =97 you can have a structure at 0xc000000000000000u (or the > same >> 32) with two pointers in it, even, one to pcpu and one to > KSTACK_PAGES direct-mapped, contiguous pages. =A0Then you can load the > kstack address or the pcpu base very quickly. =A0Of course, you can even > have a single wired entry consisting of the pcpu data and then put a > pointer to the top of the kstack in it. =A0I don't think you can get by > with no wired TLB entries, but you also don't have to index a big > array. =A0The nice thing about setting up a per-CPU TLB entry (you have > to set up at least one, the kstack, in order to be able to handle > exceptions) is that then you need only access offsets into it that are > known at compile time and constant no matter what CPU you're running > on. =A0Load the kstack by doing "ld sp, 0(0xc...)" and load the pcpu > address by doing "ld t0, 8(0xc....)". =A0Two wired entries lets you get > rid of the indirection, but you can get by with one and still not have > to do (1) run-time computation of the index into some array (2) > possibly very expensive getting of the cpuid. > >> I was even thinking get a LARGE entry.. one that is say 8 Meg >> for the kernel.. covering all text/data etc... with this >> new super page stuff. of course I have never looked into how >> its implemented.. > > That would be easy to do, but what would be the benefits of accessing > that data through a wired TLB entry instead of the direct map? > >> Yes, you pay an index reference for every access .. or at >> least one to setup a pointer.. but I think that it much cheaper >> than a TLB miss is... (words for imp to think about)... > > Yes, TLB misses are very slow. =A0Your desire to avoid adding another > wired entry seems pretty reasonable. =A0I think that using a single > wired TLB entry for a mux or for both the kstack and pcpu is easy and > usable. =A0I feel like just wiring the kstack and putting a > direct-mapped, sometimes-recomputed pointer to the pcpu into gp is the > best combination in the long run =97 even just loading an immediate > 64-bit address is pretty slow wrt how often things in the PCPU are > accessed in SMP kernels. > > Juli. > From owner-freebsd-mips@FreeBSD.ORG Fri Jan 29 16:32:08 2010 Return-Path: Delivered-To: freebsd-mips@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3FF23106566B; Fri, 29 Jan 2010 16:32:08 +0000 (UTC) (envelope-from rrs@lakerest.net) Received: from lakerest.net (unknown [IPv6:2001:240:585:2:213:d4ff:fef3:2d8d]) by mx1.freebsd.org (Postfix) with ESMTP id CE9908FC14; Fri, 29 Jan 2010 16:32:07 +0000 (UTC) Received: from mobile-166-129-160-227.mycingular.net (mobile-166-129-160-227.mycingular.net [166.129.160.227] (may be forged)) (authenticated bits=0) by lakerest.net (8.14.3/8.14.3) with ESMTP id o0TGVwjE028594 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 29 Jan 2010 11:32:05 -0500 (EST) (envelope-from rrs@lakerest.net) Message-Id: <5C3F269A-8E9A-4356-B1A1-3D503962F106@lakerest.net> From: Randall Stewart To: Neel Natu In-Reply-To: Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 29 Jan 2010 08:31:51 -0800 References: <20100128.132114.1004138037722505681.imp@bsdimp.com> <66207A08-F691-4603-A6C5-9C675414C91E@lakerest.net> <85D9D383-29A3-4F09-A2FE-61E4EA85CE9B@lakerest.net> X-Mailer: Apple Mail (2.936) Cc: freebsd-mips@freebsd.org Subject: Re: Code review: groundwork for SMP X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jan 2010 16:32:08 -0000 Neel Comments in line On Jan 29, 2010, at 7:25 AM, Neel Natu wrote: > Thanks Juli, Randall and JC for the comments. > > I think it is fair to ask that we don't burn another TLB entry to (its actually 4 if we turn on all 4 threads that are in each core for RMI.. each thread has a complete register set etc so it is a virtual cpu ;-o ) > store the pcpu data. So maybe it might help if I went through what > options I considered before settling on this one: > > - One of the first things that I did investigate was using per-cpu > scratch registers but the Sibyte did not have any and they are not > part of the MIPS architecture. Which is a shame that they are not part of the arch... but are just showing up in recent cores... but oh well... > > - The second thing I considered was using a platform-specific > getcpuid() to index into the struct pcpu pcpu[MAXCPU] array to compute > the KSEG0 address of pcpu at runtime. However this turned out to be a > bit messy because there are consumers of getcpuid() in exception > context where we are restricted to using only k0 and k1 (and sometimes > only one of them). Also, like Juli pointed out getcpuid() is slow on > some cpus and I did not want to make the assumption that one could > write getcpuid() using a single k0/k1 register. > Yep.. sounds reasonable... if getcpuid is slow this is an issue ;-0 > So, having the pcpu pointer in a TLB entry divorces us from any > assumptions about the CPU we are running on. True.. > > I think that there is a legitimate concern about this on the XLR - but > given that you are sharing the TLB among 4 threads I think there is > the bigger issue of the wired kstack entries that you need to solve > before even thinking about pcpu mapping. > Actually the 4 threads are not sharing, each thread gets its own pcpu.. which means I need 4 TLB entries.. sigh.. > I did not consider the approach suggested by Juli where the pcpu and > kstack pointers can be stashed in a single wired TLB entry. I need > some time to chew on it and prototype it. Yeah, I have not grokked this approach either.. I have to think about if it would work.. hmm but would you not have to still index which cpu you are on.. or am I missing something... maybe I need some more coffee ;-) Juli's idea about using the badaddr pointer might actually have merit.. I know it sounds weird but one could harmonize this with the scratch register idea... Basically have a marco that "updates" the pcpu pointer on any kernel entry. For systems that have a scratch register that is setup at cpu boot this is a nop. For systems that don't have scratch register this does the calculation to get the pcpu[cpuid] and throws it in the baddadr variable.. of course this would have to be after pulling out the baddaddr ;-) Then we just use a macro to access the pcpu (I think this already exists).. on systems with a scratch register it refers to the proper register.. on systems without its the badaddr register. Either way its a single register access and no TLB entries burned... And I do think we REALLY need to look into what it takes to do superpages. I know Kirk gave a presentation on them at EuroBSD and there in the kernel.. and I know we need to do something to support them. If we did that it would free up loads of TLB's since every time I am in the debugger and look at the TLB list I see ton's of kernel addresses.... We could easily map one wired TLB entry that puts the entire kernel in some large block with one TLB.. And even on RMI this would be "good" since they (all 4 threads) could share that one TLB entry for the entire kernel ;-) Just some early morning thoughts ;-0 R > > I would still like to commit this so as to keep making progress on the > SMP support. This is a small piece of the bigger goal of getting SMP > functional and can be replaced in the future if need be. > > best > Neel > > On Thu, Jan 28, 2010 at 10:42 PM, Juli Mallett =20 > wrote: >> On Thu, Jan 28, 2010 at 21:28, Randall Stewart =20 >> wrote: >>>> [ Using a single wired TLB entry for kstack and pcpu ] >>> >>> Which means you have a big array that you are offsetting. >> >> Not really =97 you can have a structure at 0xc000000000000000u (or = the >> same >> 32) with two pointers in it, even, one to pcpu and one to >> KSTACK_PAGES direct-mapped, contiguous pages. Then you can load the >> kstack address or the pcpu base very quickly. Of course, you can =20 >> even >> have a single wired entry consisting of the pcpu data and then put a >> pointer to the top of the kstack in it. I don't think you can get by >> with no wired TLB entries, but you also don't have to index a big >> array. The nice thing about setting up a per-CPU TLB entry (you have >> to set up at least one, the kstack, in order to be able to handle >> exceptions) is that then you need only access offsets into it that =20= >> are >> known at compile time and constant no matter what CPU you're running >> on. Load the kstack by doing "ld sp, 0(0xc...)" and load the pcpu >> address by doing "ld t0, 8(0xc....)". Two wired entries lets you get >> rid of the indirection, but you can get by with one and still not =20 >> have >> to do (1) run-time computation of the index into some array (2) >> possibly very expensive getting of the cpuid. >> >>> I was even thinking get a LARGE entry.. one that is say 8 Meg >>> for the kernel.. covering all text/data etc... with this >>> new super page stuff. of course I have never looked into how >>> its implemented.. >> >> That would be easy to do, but what would be the benefits of accessing >> that data through a wired TLB entry instead of the direct map? >> >>> Yes, you pay an index reference for every access .. or at >>> least one to setup a pointer.. but I think that it much cheaper >>> than a TLB miss is... (words for imp to think about)... >> >> Yes, TLB misses are very slow. Your desire to avoid adding another >> wired entry seems pretty reasonable. I think that using a single >> wired TLB entry for a mux or for both the kstack and pcpu is easy and >> usable. I feel like just wiring the kstack and putting a >> direct-mapped, sometimes-recomputed pointer to the pcpu into gp is =20= >> the >> best combination in the long run =97 even just loading an immediate >> 64-bit address is pretty slow wrt how often things in the PCPU are >> accessed in SMP kernels. >> >> Juli. >> > ------------------------------ Randall Stewart 803-317-4952 (cell) 803-345-0391(direct) From owner-freebsd-mips@FreeBSD.ORG Fri Jan 29 17:03:02 2010 Return-Path: Delivered-To: freebsd-mips@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EF6CA106568F; Fri, 29 Jan 2010 17:03:02 +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 73B6C8FC22; Fri, 29 Jan 2010 17:03:02 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.3/8.14.1) with ESMTP id o0TGxwx3032016; Fri, 29 Jan 2010 09:59:58 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Fri, 29 Jan 2010 10:00:52 -0700 (MST) Message-Id: <20100129.100052.1013538172663276257.imp@bsdimp.com> To: neelnatu@gmail.com From: "M. Warner Losh" In-Reply-To: References: <85D9D383-29A3-4F09-A2FE-61E4EA85CE9B@lakerest.net> X-Mailer: Mew version 6.3 on Emacs 22.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=utf-8 Content-Transfer-Encoding: base64 Cc: jmallett@FreeBSD.org, freebsd-mips@FreeBSD.org Subject: Re: Code review: groundwork for SMP X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jan 2010 17:03:03 -0000 R3JlZXRpbmdzIG9uZSBhbmQgYWxsLiAgVGhhbmtzIGZvciB3ZWlnaGluZyBpbiBvbiB0aGlzIGlz c3VlLg0KDQpJbiBnZW5lcmFsLCBJIGFncmVlIHdpdGggTmVlbCBoZXJlLiAgQnV0IEkgYWxzbyB0 aGluayB3ZSBuZWVkIHRvIHNlZQ0KaWYgd2UgY2FuIGJlIGZsZXhpYmxlIGFuZCBwdXNoIHRoaXMg ZG93biBpbnRvIGEgcGVyLWNwdS10eXBlDQpkZWNpc2lvbiAod2hpY2ggZGlmZmVycyBzbGlnaHRs eSBmcm9tIGEgcGVyLXBsYXRmb3JtIHR5cGUgYmVjYXVzZSB3ZQ0KY2FuIGhhdmUgYSBDUFUgYXBw ZWFyaW5nIGluIG11bHRpcGxlIHBsYXRmb3Jtcywgb3IgbXVsdGlwbGUgQ1BVcw0KYXBwZWFyaW5n IHdpdGhpbiBvbmUgcGxhdGZvcm0pLiAgSWYgd2UgbWFrZSBpdCBhIHBlci1jcHUtdHlwZQ0Kc29s dXRpb24sIHdlIGNvdWxkIGhhdmUgYSBzeXMvbWlwcy9taXBzL3BjcHVfbWFjaGRlcC5jIHdoaWNo IGRvZXMgdGhlDQpub3JtYWwgU01QIHN0dWZmLCBhcyB3ZWxsIGFzIGhhdmluZyBzeXMvbWlwcy94 bHIvcGNwdV9tYWNoZGVwLmMgd2hpY2gNCmRvZXMgc29tZXRoaW5nIG9wdGltaXplZCBmb3IgdGhl IFhMUi4gIENoYW5jZXMgYXJlIGdvb2QgdGhhdCBkaWZmZXJlbnQNCkNQVXMgd2lsbCB3YW50IHRv IGhhdmUgZGlmZmVyZW50IHRyYWRlLW9mZnMgaGVyZS4gIFdlJ2QgYWxzbyBuZWVkIHNvbWUNCndh eSB0byBlbmNvZGUgdGhpcyBpbiBhbiBpbmNsdWRlIGZpbGUsIHNvIHRoZXJlJ3Mgc29tZSB3b3Jr IHRvIG1ha2UNClBDUFUgbWFjcm8gZGlmZmVyZW50IGZvciBkaWZmZXJlbnQgQ1BVcy4uLg0KDQpX ZSBjb3VsZCBsb2FkICRncCB3aXRoIHRoZSBwZXItY3B1IGluZm8uICBUaGlzIGxvYWRpbmcgaXMg b3J0aG9nb25hbA0KdG8gdGhlIHZhbHVlIHdlIGxvYWQuICBXaXRoIE5lZWwncyBtZXRob2QsIHdl IGNvdWxkIGxvYWQgaXQgd2l0aCB0aGUNCnNhbWUgdmFsdWUgb24gdGhlIHRyaXAgaW50byB0aGUg a2VybmVsIGV2ZXJ5IHRpbWUuICBXZSBuZWVkIHRvIGxvYWQgaXQNCnRvIHNvbWUgdmFsdWUsIHNh dmluZyB0aGUgb2xkIHZhbHVlLCB3aGVuIHdlIHRyYXAgaW50byB0aGUga2VybmVsDQpiZWNhdXNl IHdlIGNhbid0IHRydXN0IHRoZSB1c2VyIHRvIG5vdCBkbyBzb21ldGhpbmcgbGlrZToNCglvciBn cCwgemVybywgemVybw0Kb3Igd29yc2UsIGNhdXNpbmcgc2VjdXJpdHkgaXNzdWVzIChwYW5pY3Ms IHdyb25nIGRhdGEgYWNjZXNzZWQsIGV0YykuDQpFdmVuIG9uIHRoZSBYTFIgaWYgd2UgaGF2ZSBs b3RzIG9mIHRyaXBzIGludG8gdGhlIGtlcm5lbCwgd2UncmUgbGlrZWx5DQp0byBwdXQgYSBsb3Qg b2YgcHJlc3N1cmUgb24gdGhlIFRMQnMgaWYgd2UncmUgY29uc3RhbnRseSBpbnN0YWxsaW5nDQpv bmUgdGhhdCBpc24ndCB3aXJlZC4gIFNvIGV2ZW4gdGhlIHBjcHVbZ2V0Y3B1aWQoKV0gbWV0aG9k IGZhaWxzIGhlcmUuDQoNClRoZSBhZHZhbnRhZ2Ugb2YgTmVlbCdzIG1ldGhvZCBpcyB0aGF0IGl0 IHdvcmtzIHdlbGwgZm9yIGEgbGFyZ2UgY2xhc3MNCm9mIFNNUCBtYWNoaW5lcywgYW5kIHRoZSBj b2RlIHBhdGggaXMgbm8gZGlmZmVyZW50IGZvciBub24tU01QDQptYWNoaW5lcyAoc2luY2UgdGhl IG5vbi1TTVAgbWFjaGluZXMgY2FuIGp1c3QgdXNlIGFuIGFkZHJlc3MgaW4gS1NFRzANCmFuZCBu b3QgbmVlZCBhbnkgVExCIGVudHJ5KS4gIEl0IGFsc28gc2NhbGVzIHdlbGwgd2l0aCB0aGUgbnVt YmVyIG9mDQpDUFVzLCBzaW5jZSBlYWNoIGFkZGl0aW9uYWwgQ1BVIGp1c3QgbmVlZHMgMiBwYWdl cyBvZiBSQU0gYW5kIHdlIGRvbid0DQpoYXZlIHRvIGJlIGxpbWl0ZWQgYnkgTUFYQ1BVLiAgTWFu eSBzeXN0ZW1zIHdpbGwgYmVuZWZpdCBmcm9tIHRoaXMgYXMNCndlbGwsIHNpbmNlLCBmb3IgZXhh bXBsZSwgdGhlIE9jdGVvbiBzdXBwb3J0cyBtdWxpcGxlIGV4ZWN1dGl2ZXMNCnBhcnRpdGlvbmlu ZyB0aGUgY29yZXMuICBJbiB0aGF0IHNjZW5hcmlvLCBGcmVlQlNEIG1heSBiZSBnaXZlbiBDUFVz IDENCmFuZCAxNSwgbGVhdmluZyBhIHJhdGhlciBsYXJnZSBnYXAgaW4gQ1BVIG51bWJlcnMgKHNp bmNlIHRoZSBNSVBTNjRyMg0KbWV0aG9kIG9mIGdldHRpbmcgdGhlIGNvcmUgcmV0dXJucyBhIHJh dyBudW1iZXIpLiAgVGhpcyBnYXAgd2lsbCBtZWFuDQphIHRhYmxlIGxvb2t1cCwgb3IgbGFyZ2Vy IHRhYmxlcy4gIEkgZG9uJ3Qga25vdyBpZiBhbGwgdGhlIGFzc3VtcHRpb25zDQphYm91dCBjb250 aWd1b3VzIENQVSBudW1iZXJzIGFyZSB5ZXQgb3V0IG9mIHRoZSBrZXJuZWwuDQoNCkkgYWxzbyB0 ZW5kIHRvIGFncmVlIHdpdGggTmVlbCB0aGF0IHBjcHVbZ2V0Y3B1aWQoKV0gbGlrZWx5IGlzIGdv aW5nDQp0byBiZSBleHBlbnNpdmUgdG8gY29tcHV0ZSBmb3IgdGhlIHRyYXAgYW5kIGludGVycnVw dCBjb250ZXh0cyB3ZSBoYXZlDQp0byBydW4gaW4uIFdlIHNob3VsZCBhdm9pZCB0aGF0IGFzIG11 Y2ggYXMgcG9zc2libGUuDQoNCk9uZSBvdGhlciBuaWNlIHNpZGUgZWZmZWN0IG9mIE5lZWwncyBz Y2hlbWUgaXMgdGhhdCB5b3UgY2FuIGhhdmUgTVANCmFuZCAhTVAga2VybmVsIG1vZHVsZXMgdGhh dCB1c2UgdGhlIHNhbWUgbWV0aG9kIHRvIGdldCBwY3B1IGRhdGEuICBCdXQNCnRoYXQncyBhIG1p bm9yIHBvaW50IGF0IHRoaXMgc3RhZ2Ugb2YgdGhlIGdhbWUuDQoNClRoZSBYTFIgd2lsbCBoYXZl IHNjaGVkdWxlciBjaGFsbGVuZ2VzIGFzIHdlbGwuICBJdCB3aWxsIHB1c2ggdGhlDQpkZXNpZ24g YXNzdW1wdGlvbnMgb2YgVUxFIGJleW9uZCB0aGUgYnJlYWtpbmcgcG9pbnQsIEkgZmVhci4NCkh5 cGVydGhyZWFkaW5nIGFscmVhZHkgZXhpc3RzIG9uIGludGVsLCBhbmQgVUxFIGNvcGVzLCBhIGJp dCwgd2l0aA0KaXQuICBCdXQgd2l0aCB0aGUgaGlnaCBudW1iZXIgb2YgdGhyZWFkcyBlYWNoIENQ VSBjYW4gaGF2ZSwgd2UgbWF5DQpuZWVkIHNvbWV0aGluZyB3aXRoIGEgbGl0dGxlIG1vcmUgc21h cnRzLiAgU29tZXRoaW5nIHRoYXQga25vd3MgaXQNCm1pZ2h0IGJlIGJldHRlciB0byBzY2hlZHVs ZSB0d28gZGlmZmVyZW50IHByb2Nlc3NlcyBvbiB0d28gZGlmZmVyZW50DQpjb3JlcywgYW5kIGxl YXZlIHNvbWUgb2YgdGhlIHRocmVhZHMgaWRsZSB0byByZWR1Y2UgVExCIHByZXNzdXJlLCBmb3IN CmV4YW1wbGUuDQoNClBlciBDUFUgc2NyYXRjaCByZWdpc3RlcnMgZG8gbm90IGV4aXN0IG9uIE1J UFMsIGluIGdlbmVyYWwuICBTb21lIENQVXMNCmhhdmUgdGhlbSwgYW5kIG1hbnkgZG8gbm90LiAg Q1AwIHJlZ2lzdGVycyBhcmUgcGxlbnRpZnVsIGluIG1vcmUNCm1vZGVybiBkZXNpZ25zLCBhbmQg c29tZSBvZiB0aGVtIG1heSBldmVuIGJlIHVzZWZ1bCBmb3Igb3VyIG5lZWRzLg0KSG93ZXZlciwg bWZjMCBhbmQgbXRjMCBvZnRlbiBoYXZlIHBpcGVsaW5lIGhhemFyZHMgYXNzb2NpYXRlZCB3aXRo DQp0aGVtIHdoaWNoIHdpbGwgdHJpcCB1cCB0aGUgdW53YXJ5LiAgV2hlbiByZWFkaW5nIHRoZSBo aXN0b3JpY2FsDQplcnJhdGEgZm9yIE1JUFMgQ1BVcywgd2Ugb2Z0ZW4gZmluZCB0aGF0IHRoaXMg aXMgd2hlcmUgd2UgbmVlZCB0byBkbw0KdGhlIG1vc3Qgd29ya2Fyb3VuZHMuDQoNCkkgZ3Vlc3Mg dGhpcyBpcyBhIGxvbmcgd2F5IHRvIHNheSAiSSB0aGluayB3ZSBzaG91bGQgY29tbWl0IE5lZWwn cw0KcGF0Y2hlcy4gIFdlIHNob3VsZCB3b3JrIGFsb25nIHR3byBmcm9udHM6ICgxKSBpbXBsZW1l bnRpbmcgSnVsaSdzDQppZGVhIG9mIHNoYXJpbmcga3N0YWNrIGFuZCBwY3B1IGRhdGEgaW4gb25l IFRMQiBhbmQgKDIpIG1ha2luZyBpdCBzbw0KdGhhdCBDUFVzIHdoZXJlIHRoaXMgaXMgc3ViLW9w dGltYWwgY2FuIHN3YXAgaW4gdGhlaXIgb3duDQppbXBsZW1lbnRhdGlvbi4iDQoNCldhcm5lcg0K DQpJbiBtZXNzYWdlOiA8ZGZmZTg0ODMxMDAxMjkwNzI1ZzJjYTI1NzRhcDIyYjgyZjJhZDM4YWYy ZDZAbWFpbC5nbWFpbC5jb20+DQogICAgICAgICAgICBOZWVsIE5hdHUgPG5lZWxuYXR1QGdtYWls LmNvbT4gd3JpdGVzOg0KOiBUaGFua3MgSnVsaSwgUmFuZGFsbCBhbmQgSkMgZm9yIHRoZSBjb21t ZW50cy4NCjogDQo6IEkgdGhpbmsgaXQgaXMgZmFpciB0byBhc2sgdGhhdCB3ZSBkb24ndCBidXJu IGFub3RoZXIgVExCIGVudHJ5IHRvDQo6IHN0b3JlIHRoZSBwY3B1IGRhdGEuIFNvIG1heWJlIGl0 IG1pZ2h0IGhlbHAgaWYgSSB3ZW50IHRocm91Z2ggd2hhdA0KOiBvcHRpb25zIEkgY29uc2lkZXJl ZCBiZWZvcmUgc2V0dGxpbmcgb24gdGhpcyBvbmU6DQo6IA0KOiAtIE9uZSBvZiB0aGUgZmlyc3Qg dGhpbmdzIHRoYXQgSSBkaWQgaW52ZXN0aWdhdGUgd2FzIHVzaW5nIHBlci1jcHUNCjogc2NyYXRj aCByZWdpc3RlcnMgYnV0IHRoZSBTaWJ5dGUgZGlkIG5vdCBoYXZlIGFueSBhbmQgdGhleSBhcmUg bm90DQo6IHBhcnQgb2YgdGhlIE1JUFMgYXJjaGl0ZWN0dXJlLg0KOiANCjogLSBUaGUgc2Vjb25k IHRoaW5nIEkgY29uc2lkZXJlZCB3YXMgdXNpbmcgYSBwbGF0Zm9ybS1zcGVjaWZpYw0KOiBnZXRj cHVpZCgpIHRvIGluZGV4IGludG8gdGhlIHN0cnVjdCBwY3B1IHBjcHVbTUFYQ1BVXSBhcnJheSB0 byBjb21wdXRlDQo6IHRoZSBLU0VHMCBhZGRyZXNzIG9mIHBjcHUgYXQgcnVudGltZS4gSG93ZXZl ciB0aGlzIHR1cm5lZCBvdXQgdG8gYmUgYQ0KOiBiaXQgbWVzc3kgYmVjYXVzZSB0aGVyZSBhcmUg Y29uc3VtZXJzIG9mIGdldGNwdWlkKCkgaW4gZXhjZXB0aW9uDQo6IGNvbnRleHQgd2hlcmUgd2Ug YXJlIHJlc3RyaWN0ZWQgdG8gdXNpbmcgb25seSBrMCBhbmQgazEgKGFuZCBzb21ldGltZXMNCjog b25seSBvbmUgb2YgdGhlbSkuIEFsc28sIGxpa2UgSnVsaSBwb2ludGVkIG91dCBnZXRjcHVpZCgp IGlzIHNsb3cgb24NCjogc29tZSBjcHVzIGFuZCBJIGRpZCBub3Qgd2FudCB0byBtYWtlIHRoZSBh c3N1bXB0aW9uIHRoYXQgb25lIGNvdWxkDQo6IHdyaXRlIGdldGNwdWlkKCkgdXNpbmcgYSBzaW5n bGUgazAvazEgcmVnaXN0ZXIuDQo6IA0KOiBTbywgaGF2aW5nIHRoZSBwY3B1IHBvaW50ZXIgaW4g YSBUTEIgZW50cnkgZGl2b3JjZXMgdXMgZnJvbSBhbnkNCjogYXNzdW1wdGlvbnMgYWJvdXQgdGhl IENQVSB3ZSBhcmUgcnVubmluZyBvbi4NCjogDQo6IEkgdGhpbmsgdGhhdCB0aGVyZSBpcyBhIGxl Z2l0aW1hdGUgY29uY2VybiBhYm91dCB0aGlzIG9uIHRoZSBYTFIgLSBidXQNCjogZ2l2ZW4gdGhh dCB5b3UgYXJlIHNoYXJpbmcgdGhlIFRMQiBhbW9uZyA0IHRocmVhZHMgSSB0aGluayB0aGVyZSBp cw0KOiB0aGUgYmlnZ2VyIGlzc3VlIG9mIHRoZSB3aXJlZCBrc3RhY2sgZW50cmllcyB0aGF0IHlv dSBuZWVkIHRvIHNvbHZlDQo6IGJlZm9yZSBldmVuIHRoaW5raW5nIGFib3V0IHBjcHUgbWFwcGlu Zy4NCjogDQo6IEkgZGlkIG5vdCBjb25zaWRlciB0aGUgYXBwcm9hY2ggc3VnZ2VzdGVkIGJ5IEp1 bGkgd2hlcmUgdGhlIHBjcHUgYW5kDQo6IGtzdGFjayBwb2ludGVycyBjYW4gYmUgc3Rhc2hlZCBp biBhIHNpbmdsZSB3aXJlZCBUTEIgZW50cnkuIEkgbmVlZA0KOiBzb21lIHRpbWUgdG8gY2hldyBv biBpdCBhbmQgcHJvdG90eXBlIGl0Lg0KOiANCjogSSB3b3VsZCBzdGlsbCBsaWtlIHRvIGNvbW1p dCB0aGlzIHNvIGFzIHRvIGtlZXAgbWFraW5nIHByb2dyZXNzIG9uIHRoZQ0KOiBTTVAgc3VwcG9y dC4gVGhpcyBpcyBhIHNtYWxsIHBpZWNlIG9mIHRoZSBiaWdnZXIgZ29hbCBvZiBnZXR0aW5nIFNN UA0KOiBmdW5jdGlvbmFsIGFuZCBjYW4gYmUgcmVwbGFjZWQgaW4gdGhlIGZ1dHVyZSBpZiBuZWVk IGJlLg0KOiANCjogYmVzdA0KOiBOZWVsDQo6IA0KOiBPbiBUaHUsIEphbiAyOCwgMjAxMCBhdCAx MDo0MiBQTSwgSnVsaSBNYWxsZXR0IDxqbWFsbGV0dEBmcmVlYnNkLm9yZz4gd3JvdGU6DQo6ID4g T24gVGh1LCBKYW4gMjgsIDIwMTAgYXQgMjE6MjgsIFJhbmRhbGwgU3Rld2FydCA8cnJzQGxha2Vy ZXN0Lm5ldD4gd3JvdGU6DQo6ID4+PiBbIFVzaW5nIGEgc2luZ2xlIHdpcmVkIFRMQiBlbnRyeSBm b3Iga3N0YWNrIGFuZCBwY3B1IF0NCjogPj4NCjogPj4gV2hpY2ggbWVhbnMgeW91IGhhdmUgYSBi aWcgYXJyYXkgdGhhdCB5b3UgYXJlIG9mZnNldHRpbmcuDQo6ID4NCjogPiBOb3QgcmVhbGx5IOKA lCB5b3UgY2FuIGhhdmUgYSBzdHJ1Y3R1cmUgYXQgMHhjMDAwMDAwMDAwMDAwMDAwdSAob3IgdGhl DQo6ID4gc2FtZSA+PiAzMikgd2l0aCB0d28gcG9pbnRlcnMgaW4gaXQsIGV2ZW4sIG9uZSB0byBw Y3B1IGFuZCBvbmUgdG8NCjogPiBLU1RBQ0tfUEFHRVMgZGlyZWN0LW1hcHBlZCwgY29udGlndW91 cyBwYWdlcy4gwqBUaGVuIHlvdSBjYW4gbG9hZCB0aGUNCjogPiBrc3RhY2sgYWRkcmVzcyBvciB0 aGUgcGNwdSBiYXNlIHZlcnkgcXVpY2tseS4gwqBPZiBjb3Vyc2UsIHlvdSBjYW4gZXZlbg0KOiA+ IGhhdmUgYSBzaW5nbGUgd2lyZWQgZW50cnkgY29uc2lzdGluZyBvZiB0aGUgcGNwdSBkYXRhIGFu ZCB0aGVuIHB1dCBhDQo6ID4gcG9pbnRlciB0byB0aGUgdG9wIG9mIHRoZSBrc3RhY2sgaW4gaXQu IMKgSSBkb24ndCB0aGluayB5b3UgY2FuIGdldCBieQ0KOiA+IHdpdGggbm8gd2lyZWQgVExCIGVu dHJpZXMsIGJ1dCB5b3UgYWxzbyBkb24ndCBoYXZlIHRvIGluZGV4IGEgYmlnDQo6ID4gYXJyYXku IMKgVGhlIG5pY2UgdGhpbmcgYWJvdXQgc2V0dGluZyB1cCBhIHBlci1DUFUgVExCIGVudHJ5ICh5 b3UgaGF2ZQ0KOiA+IHRvIHNldCB1cCBhdCBsZWFzdCBvbmUsIHRoZSBrc3RhY2ssIGluIG9yZGVy IHRvIGJlIGFibGUgdG8gaGFuZGxlDQo6ID4gZXhjZXB0aW9ucykgaXMgdGhhdCB0aGVuIHlvdSBu ZWVkIG9ubHkgYWNjZXNzIG9mZnNldHMgaW50byBpdCB0aGF0IGFyZQ0KOiA+IGtub3duIGF0IGNv bXBpbGUgdGltZSBhbmQgY29uc3RhbnQgbm8gbWF0dGVyIHdoYXQgQ1BVIHlvdSdyZSBydW5uaW5n DQo6ID4gb24uIMKgTG9hZCB0aGUga3N0YWNrIGJ5IGRvaW5nICJsZCBzcCwgMCgweGMuLi4pIiBh bmQgbG9hZCB0aGUgcGNwdQ0KOiA+IGFkZHJlc3MgYnkgZG9pbmcgImxkIHQwLCA4KDB4Yy4uLi4p Ii4gwqBUd28gd2lyZWQgZW50cmllcyBsZXRzIHlvdSBnZXQNCjogPiByaWQgb2YgdGhlIGluZGly ZWN0aW9uLCBidXQgeW91IGNhbiBnZXQgYnkgd2l0aCBvbmUgYW5kIHN0aWxsIG5vdCBoYXZlDQo6 ID4gdG8gZG8gKDEpIHJ1bi10aW1lIGNvbXB1dGF0aW9uIG9mIHRoZSBpbmRleCBpbnRvIHNvbWUg YXJyYXkgKDIpDQo6ID4gcG9zc2libHkgdmVyeSBleHBlbnNpdmUgZ2V0dGluZyBvZiB0aGUgY3B1 aWQuDQo6ID4NCjogPj4gSSB3YXMgZXZlbiB0aGlua2luZyBnZXQgYSBMQVJHRSBlbnRyeS4uIG9u ZSB0aGF0IGlzIHNheSA4IE1lZw0KOiA+PiBmb3IgdGhlIGtlcm5lbC4uIGNvdmVyaW5nIGFsbCB0 ZXh0L2RhdGEgZXRjLi4uIHdpdGggdGhpcw0KOiA+PiBuZXcgc3VwZXIgcGFnZSBzdHVmZi4gb2Yg Y291cnNlIEkgaGF2ZSBuZXZlciBsb29rZWQgaW50byBob3cNCjogPj4gaXRzIGltcGxlbWVudGVk Li4NCjogPg0KOiA+IFRoYXQgd291bGQgYmUgZWFzeSB0byBkbywgYnV0IHdoYXQgd291bGQgYmUg dGhlIGJlbmVmaXRzIG9mIGFjY2Vzc2luZw0KOiA+IHRoYXQgZGF0YSB0aHJvdWdoIGEgd2lyZWQg VExCIGVudHJ5IGluc3RlYWQgb2YgdGhlIGRpcmVjdCBtYXA/DQo6ID4NCjogPj4gWWVzLCB5b3Ug cGF5IGFuIGluZGV4IHJlZmVyZW5jZSBmb3IgZXZlcnkgYWNjZXNzIC4uIG9yIGF0DQo6ID4+IGxl YXN0IG9uZSB0byBzZXR1cCBhIHBvaW50ZXIuLiBidXQgSSB0aGluayB0aGF0IGl0IG11Y2ggY2hl YXBlcg0KOiA+PiB0aGFuIGEgVExCIG1pc3MgaXMuLi4gKHdvcmRzIGZvciBpbXAgdG8gdGhpbmsg YWJvdXQpLi4uDQo6ID4NCjogPiBZZXMsIFRMQiBtaXNzZXMgYXJlIHZlcnkgc2xvdy4gwqBZb3Vy IGRlc2lyZSB0byBhdm9pZCBhZGRpbmcgYW5vdGhlcg0KOiA+IHdpcmVkIGVudHJ5IHNlZW1zIHBy ZXR0eSByZWFzb25hYmxlLiDCoEkgdGhpbmsgdGhhdCB1c2luZyBhIHNpbmdsZQ0KOiA+IHdpcmVk IFRMQiBlbnRyeSBmb3IgYSBtdXggb3IgZm9yIGJvdGggdGhlIGtzdGFjayBhbmQgcGNwdSBpcyBl YXN5IGFuZA0KOiA+IHVzYWJsZS4gwqBJIGZlZWwgbGlrZSBqdXN0IHdpcmluZyB0aGUga3N0YWNr IGFuZCBwdXR0aW5nIGENCjogPiBkaXJlY3QtbWFwcGVkLCBzb21ldGltZXMtcmVjb21wdXRlZCBw b2ludGVyIHRvIHRoZSBwY3B1IGludG8gZ3AgaXMgdGhlDQo6ID4gYmVzdCBjb21iaW5hdGlvbiBp biB0aGUgbG9uZyBydW4g4oCUIGV2ZW4ganVzdCBsb2FkaW5nIGFuIGltbWVkaWF0ZQ0KOiA+IDY0 LWJpdCBhZGRyZXNzIGlzIHByZXR0eSBzbG93IHdydCBob3cgb2Z0ZW4gdGhpbmdzIGluIHRoZSBQ Q1BVIGFyZQ0KOiA+IGFjY2Vzc2VkIGluIFNNUCBrZXJuZWxzLg0KOiA+DQo6ID4gSnVsaS4NCjog Pg0KOiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KOiBm cmVlYnNkLW1pcHNAZnJlZWJzZC5vcmcgbWFpbGluZyBsaXN0DQo6IGh0dHA6Ly9saXN0cy5mcmVl YnNkLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2ZyZWVic2QtbWlwcw0KOiBUbyB1bnN1YnNjcmliZSwg c2VuZCBhbnkgbWFpbCB0byAiZnJlZWJzZC1taXBzLXVuc3Vic2NyaWJlQGZyZWVic2Qub3JnIg0K OiANCjogDQo= From owner-freebsd-mips@FreeBSD.ORG Fri Jan 29 17:17:49 2010 Return-Path: Delivered-To: freebsd-mips@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E0A411065693 for ; Fri, 29 Jan 2010 17:17:49 +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 7A3EB8FC1F for ; Fri, 29 Jan 2010 17:17:49 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.3/8.14.1) with ESMTP id o0TH87dP032081; Fri, 29 Jan 2010 10:08:07 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Fri, 29 Jan 2010 10:09:02 -0700 (MST) Message-Id: <20100129.100902.775474398290145730.imp@bsdimp.com> To: rrs@lakerest.net From: "M. Warner Losh" In-Reply-To: <5C3F269A-8E9A-4356-B1A1-3D503962F106@lakerest.net> References: <5C3F269A-8E9A-4356-B1A1-3D503962F106@lakerest.net> X-Mailer: Mew version 6.3 on Emacs 22.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=utf-8 Content-Transfer-Encoding: base64 Cc: freebsd-mips@FreeBSD.org, neelnatu@gmail.com Subject: Re: Code review: groundwork for SMP X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jan 2010 17:17:50 -0000 SW4gbWVzc2FnZTogPDVDM0YyNjlBLThFOUEtNDM1Ni1CMUExLTNENTAzOTYyRjEwNkBsYWtlcmVz dC5uZXQ+DQogICAgICAgICAgICBSYW5kYWxsIFN0ZXdhcnQgPHJyc0BsYWtlcmVzdC5uZXQ+IHdy aXRlczoNCjogTmVlbA0KOiANCjogQ29tbWVudHMgaW4gbGluZQ0KOiANCjogDQo6IE9uIEphbiAy OSwgMjAxMCwgYXQgNzoyNSBBTSwgTmVlbCBOYXR1IHdyb3RlOg0KOiANCjogPiBUaGFua3MgSnVs aSwgUmFuZGFsbCBhbmQgSkMgZm9yIHRoZSBjb21tZW50cy4NCjogPg0KOiA+IEkgdGhpbmsgaXQg aXMgZmFpciB0byBhc2sgdGhhdCB3ZSBkb24ndCBidXJuIGFub3RoZXIgVExCIGVudHJ5IHRvDQo6 IA0KOiAoaXRzIGFjdHVhbGx5IDQgaWYgd2UgdHVybiBvbiBhbGwgNCB0aHJlYWRzIHRoYXQgYXJl IGluIGVhY2gNCjogIGNvcmUgZm9yIFJNSS4uIGVhY2ggdGhyZWFkIGhhcyBhIGNvbXBsZXRlIHJl Z2lzdGVyIHNldCBldGMgc28NCjogIGl0IGlzIGEgdmlydHVhbCBjcHUgOy1vICkNCg0KWWVzLiAg VGhhdCBtaWdodCBiZSBhIHByb2JsZW0uICBZb3UgYXJlIG1vZGVsaW5nIGEgcGFydGlhbCBDUFUg YXMgYQ0KZnVsbCBDUFUuLi4gIFRoYXQncyBvbmUgcmVhc29uIHR1cm5pbmcgb24gaHlwZXJ0aHJl YWRpbmcgZm9yIG1hbnkNCmFwcGxpY2F0aW9uIHdvcmsgbG9hZHMgb24gb2xkZXIgSW50ZWwgQ1BV cyBwcm9kdWNlZCB3b3JzZSByZXN1bHRzIHRoYW4NCndpdGggaXQgb2ZmLi4uDQoNCjogPiBzdG9y ZSB0aGUgcGNwdSBkYXRhLiBTbyBtYXliZSBpdCBtaWdodCBoZWxwIGlmIEkgd2VudCB0aHJvdWdo IHdoYXQNCjogPiBvcHRpb25zIEkgY29uc2lkZXJlZCBiZWZvcmUgc2V0dGxpbmcgb24gdGhpcyBv bmU6DQo6ID4NCjogPiAtIE9uZSBvZiB0aGUgZmlyc3QgdGhpbmdzIHRoYXQgSSBkaWQgaW52ZXN0 aWdhdGUgd2FzIHVzaW5nIHBlci1jcHUNCjogPiBzY3JhdGNoIHJlZ2lzdGVycyBidXQgdGhlIFNp Ynl0ZSBkaWQgbm90IGhhdmUgYW55IGFuZCB0aGV5IGFyZSBub3QNCjogPiBwYXJ0IG9mIHRoZSBN SVBTIGFyY2hpdGVjdHVyZS4NCjogDQo6IFdoaWNoIGlzIGEgc2hhbWUgdGhhdCB0aGV5IGFyZSBu b3QgcGFydCBvZiB0aGUgYXJjaC4uLiBidXQgYXJlDQo6IGp1c3Qgc2hvd2luZyB1cCBpbiByZWNl bnQgY29yZXMuLi4gYnV0IG9oIHdlbGwuLi4NCg0KWWVhLiAgV2UgaGF2ZSB0byB0YWtlIG91ciBt ZWRpY2luZSA6KQ0KDQo6ID4gLSBUaGUgc2Vjb25kIHRoaW5nIEkgY29uc2lkZXJlZCB3YXMgdXNp bmcgYSBwbGF0Zm9ybS1zcGVjaWZpYw0KOiA+IGdldGNwdWlkKCkgdG8gaW5kZXggaW50byB0aGUg c3RydWN0IHBjcHUgcGNwdVtNQVhDUFVdIGFycmF5IHRvIGNvbXB1dGUNCjogPiB0aGUgS1NFRzAg YWRkcmVzcyBvZiBwY3B1IGF0IHJ1bnRpbWUuIEhvd2V2ZXIgdGhpcyB0dXJuZWQgb3V0IHRvIGJl IGENCjogPiBiaXQgbWVzc3kgYmVjYXVzZSB0aGVyZSBhcmUgY29uc3VtZXJzIG9mIGdldGNwdWlk KCkgaW4gZXhjZXB0aW9uDQo6ID4gY29udGV4dCB3aGVyZSB3ZSBhcmUgcmVzdHJpY3RlZCB0byB1 c2luZyBvbmx5IGswIGFuZCBrMSAoYW5kIHNvbWV0aW1lcw0KOiA+IG9ubHkgb25lIG9mIHRoZW0p LiBBbHNvLCBsaWtlIEp1bGkgcG9pbnRlZCBvdXQgZ2V0Y3B1aWQoKSBpcyBzbG93IG9uDQo6ID4g c29tZSBjcHVzIGFuZCBJIGRpZCBub3Qgd2FudCB0byBtYWtlIHRoZSBhc3N1bXB0aW9uIHRoYXQg b25lIGNvdWxkDQo6ID4gd3JpdGUgZ2V0Y3B1aWQoKSB1c2luZyBhIHNpbmdsZSBrMC9rMSByZWdp c3Rlci4NCjogPg0KOiBZZXAuLiBzb3VuZHMgcmVhc29uYWJsZS4uLiBpZiBnZXRjcHVpZCBpcyBz bG93IHRoaXMgaXMgYW4gaXNzdWUgOy0wDQo6IA0KOiA+IFNvLCBoYXZpbmcgdGhlIHBjcHUgcG9p bnRlciBpbiBhIFRMQiBlbnRyeSBkaXZvcmNlcyB1cyBmcm9tIGFueQ0KOiA+IGFzc3VtcHRpb25z IGFib3V0IHRoZSBDUFUgd2UgYXJlIHJ1bm5pbmcgb24uDQo6IA0KOiANCjogVHJ1ZS4uDQo6ID4N CjogPiBJIHRoaW5rIHRoYXQgdGhlcmUgaXMgYSBsZWdpdGltYXRlIGNvbmNlcm4gYWJvdXQgdGhp cyBvbiB0aGUgWExSIC0gYnV0DQo6ID4gZ2l2ZW4gdGhhdCB5b3UgYXJlIHNoYXJpbmcgdGhlIFRM QiBhbW9uZyA0IHRocmVhZHMgSSB0aGluayB0aGVyZSBpcw0KOiA+IHRoZSBiaWdnZXIgaXNzdWUg b2YgdGhlIHdpcmVkIGtzdGFjayBlbnRyaWVzIHRoYXQgeW91IG5lZWQgdG8gc29sdmUNCjogPiBi ZWZvcmUgZXZlbiB0aGlua2luZyBhYm91dCBwY3B1IG1hcHBpbmcuDQo6ID4NCjogDQo6IEFjdHVh bGx5IHRoZSA0IHRocmVhZHMgYXJlIG5vdCBzaGFyaW5nLCBlYWNoIHRocmVhZCBnZXRzIGl0cyBv d24NCjogcGNwdS4uIHdoaWNoIG1lYW5zIEkgbmVlZCA0IFRMQiBlbnRyaWVzLi4gc2lnaC4uDQoN Ck1heWJlIHdlIG5lZWQgdG8gaGF2ZSBhIGJldHRlciBtb2RlbCBmb3IgdGhlIHRocmVhZHMgdGhl bj8gIEJ1dCB0aGF0J3MNCmJleW9uZCB0aGUgc2NvcGUgb2YgdGhpcyBleGVyY2lzZSA6KQ0KDQo6 ID4gSSBkaWQgbm90IGNvbnNpZGVyIHRoZSBhcHByb2FjaCBzdWdnZXN0ZWQgYnkgSnVsaSB3aGVy ZSB0aGUgcGNwdSBhbmQNCjogPiBrc3RhY2sgcG9pbnRlcnMgY2FuIGJlIHN0YXNoZWQgaW4gYSBz aW5nbGUgd2lyZWQgVExCIGVudHJ5LiBJIG5lZWQNCjogPiBzb21lIHRpbWUgdG8gY2hldyBvbiBp dCBhbmQgcHJvdG90eXBlIGl0Lg0KOiANCjogWWVhaCwgSSBoYXZlIG5vdCBncm9ra2VkIHRoaXMg YXBwcm9hY2ggZWl0aGVyLi4gSSBoYXZlIHRvDQo6IHRoaW5rIGFib3V0IGlmIGl0IHdvdWxkIHdv cmsuLiBobW0gYnV0IHdvdWxkIHlvdSBub3QgaGF2ZSB0bw0KOiBzdGlsbCBpbmRleCB3aGljaCBj cHUgeW91IGFyZSBvbi4uIG9yIGFtIEkgbWlzc2luZyBzb21ldGhpbmcuLi4gbWF5YmUNCjogSSBu ZWVkIHNvbWUgbW9yZSBjb2ZmZWUgOy0pDQoNClRoZSBpZGVhIGhlcmUgaXMgdGhhdCB5b3UgbmVl ZCBhIGtzdGFjayBlbnRyeSBBTllXQVkgdG8gZG8gYW55dGhpbmcNCnVzZWZ1bCB3aXRoIHRoZSB0 aHJlYWQgaW4gdGhlIGtlcm5lbC4gIEp1c3QgZXhwYW5kIGl0IGEgbGl0dGxlIHRvDQppbmNsdWRl IHBjcHUuDQoNCjogSnVsaSdzIGlkZWEgYWJvdXQgdXNpbmcgdGhlIGJhZGFkZHIgcG9pbnRlciBt aWdodCBhY3R1YWxseSBoYXZlDQo6IG1lcml0Li4gSSBrbm93IGl0IHNvdW5kcyB3ZWlyZCBidXQg b25lIGNvdWxkIGhhcm1vbml6ZSB0aGlzIHdpdGgNCjogdGhlIHNjcmF0Y2ggcmVnaXN0ZXIgaWRl YS4uLg0KDQpJIHRoaW5rIHRoYXQgdGhpcyBpZGVhIG5lZWRzIGEgbG90IG9mIHJlc2VhcmNoLiAg SXQgaXMgdW5jbGVhciB0byBtZQ0KdGhlIGV4dGVudCB0byB3aGljaCB2YWx1ZXMgdGhhdCBhcmUg d3JpdHRlbiB0byB0aGlzIHJlZ2lzdGVyIHBlcnNpc3QuDQpQbHVzLCBtb3ZpbmcgdG8gYW5kIGZy b20gQ1AwIHRha2VzIGEgYml0IG9mIGRvaW5nIGZvciB0aGUgQ1BVLCBhbmQNCmhpc3RvcmljYWxs eSBtb3N0IG9mIHRoZSBlcnJhdGEgZm9yIENQVXMgYXJlIGluIHRoZSBDUDAgaGFuZGxpbmcuDQoN CjogQmFzaWNhbGx5IGhhdmUgYSBtYXJjbyB0aGF0ICJ1cGRhdGVzIiB0aGUgcGNwdSBwb2ludGVy IG9uDQo6IGFueSBrZXJuZWwgZW50cnkuIEZvciBzeXN0ZW1zIHRoYXQgaGF2ZSBhIHNjcmF0Y2gg cmVnaXN0ZXIgdGhhdA0KOiBpcyBzZXR1cCBhdCBjcHUgYm9vdCB0aGlzIGlzIGEgbm9wLiBGb3Ig c3lzdGVtcyB0aGF0IGRvbid0IGhhdmUNCjogc2NyYXRjaCByZWdpc3RlciB0aGlzIGRvZXMgdGhl IGNhbGN1bGF0aW9uIHRvIGdldCB0aGUgcGNwdVtjcHVpZF0gYW5kDQo6IHRocm93cyBpdCBpbiB0 aGUgYmFkZGFkciB2YXJpYWJsZS4uIG9mIGNvdXJzZSB0aGlzIHdvdWxkIGhhdmUgdG8NCjogYmUg YWZ0ZXIgcHVsbGluZyBvdXQgdGhlIGJhZGRhZGRyIDstKQ0KOiANCjogVGhlbiB3ZSBqdXN0IHVz ZSBhIG1hY3JvIHRvIGFjY2VzcyB0aGUgcGNwdSAoSSB0aGluayB0aGlzIGFscmVhZHkNCjogZXhp c3RzKS4uIG9uIHN5c3RlbXMgd2l0aCBhIHNjcmF0Y2ggcmVnaXN0ZXIgaXQgcmVmZXJzIHRvIHRo ZQ0KOiBwcm9wZXIgcmVnaXN0ZXIuLiBvbiBzeXN0ZW1zIHdpdGhvdXQgaXRzIHRoZSBiYWRhZGRy IHJlZ2lzdGVyLg0KOiANCjogRWl0aGVyIHdheSBpdHMgYSBzaW5nbGUgcmVnaXN0ZXIgYWNjZXNz IGFuZCBubyBUTEIgZW50cmllcyBidXJuZWQuLi4NCg0KV2VsbCwgdGhhdCdzIG5vdCBlbnRpcmVs eSB0cnVlLiAgVGhlIGluc3RhbnQgeW91IHRvdWNoIHRoZSBQQ1BVIGRhdGEsDQp5b3UnbGwgaGF2 ZSB0byBnbyB0aHJvdWdoIGVpdGhlciBhIEtTRUcwIG1hcHBpbmcsIG9yIGEgVExCIGVudHJ5Lg0K DQo6IEFuZCBJIGRvIHRoaW5rIHdlIFJFQUxMWSBuZWVkIHRvIGxvb2sgaW50byB3aGF0IGl0IHRh a2VzIHRvDQo6IGRvIHN1cGVycGFnZXMuIEkga25vdyBLaXJrIGdhdmUgYSBwcmVzZW50YXRpb24g b24gdGhlbSBhdA0KOiBFdXJvQlNEIGFuZCB0aGVyZSBpbiB0aGUga2VybmVsLi4gYW5kIEkga25v dyB3ZSBuZWVkIHRvDQo6IGRvIHNvbWV0aGluZyB0byBzdXBwb3J0IHRoZW0uIElmIHdlIGRpZCB0 aGF0IGl0IHdvdWxkIGZyZWUNCjogdXAgbG9hZHMgb2YgVExCJ3Mgc2luY2UgZXZlcnkgdGltZSBJ IGFtIGluIHRoZSBkZWJ1Z2dlciBhbmQNCjogbG9vayBhdCB0aGUgVExCIGxpc3QgSSBzZWUgdG9u J3Mgb2Yga2VybmVsIGFkZHJlc3Nlcy4uLi4NCg0KQWxhbiBDb3ggaGFkIGEgc3R1ZGVudCBpbnRl cmVzdGVkIGluIGltcGxlbWVudGluZyB0aGVtIGZvciBNaXBzIGJlZm9yZQ0KTm92YS9CU0Qgd2Fz IGNhbmNlbGxlZC4gIEl0IHNlZW1lZCB0byBiZSBnb29kIGZvciBhIG1hc3RlcidzIG9yIFBoRA0K dGhlc2lzLCBmcm9tIHdoYXQgSSByZWNhbGwgYXQgdGhlIHRpbWUuLi4NCg0KOiBXZSBjb3VsZCBl YXNpbHkgbWFwIG9uZSB3aXJlZCBUTEIgZW50cnkgdGhhdCBwdXRzIHRoZSBlbnRpcmUNCjoga2Vy bmVsIGluIHNvbWUgbGFyZ2UgYmxvY2sgd2l0aCBvbmUgVExCLi4gQW5kIGV2ZW4gb24gUk1JDQo6 IHRoaXMgd291bGQgYmUgImdvb2QiIHNpbmNlIHRoZXkgKGFsbCA0IHRocmVhZHMpIGNvdWxkIHNo YXJlIHRoYXQgb25lDQo6IFRMQiBlbnRyeSBmb3IgdGhlIGVudGlyZSBrZXJuZWwgOy0pDQoNCldl bGwsIHRoZSBlbnRpcmUga2VybmVsIENPREUgaXMgYWxyZWFkeSBpbiBvbmUgZ2lhbnQgVExCIGVu dHJ5IHRoYXQNCmRvZXNuJ3QgYnVybiBhIFRMQiBlbnRyeTogS1NFRzAgOikuICBUaGUgY29kZSwg ZGF0YSBhbmQgQlNTIGVudHJpZXMgaW4NCnRoYXQgYXJlYSBhcmUgYWxsIHJlZmVyZW5jZSB0aHJv dWdoIGtzZWcwLiAgYSBzaW1wbGUgcGNwdVtdIGFycmF5DQp3b3VsZCBsaXZlIGluIGtzZWcwLiAg QnV0IHdpdGggdGhlIG5ldyBkeW5hbWljIHBjcHUgc3R1ZmYsIHdlJ2QgaGF2ZQ0KdG8gYmUgY2Fy ZWZ1bCBzaW5jZSB0aGF0IGlzIG1hbGxvY2VkIGFuZCBkb2Vzbid0IGxvdmUgaW4ga3NlZzAgd2l0 aG91dA0Kc3BlY2lhbCBtYWdpYy4NCg0KV2FybmVyDQoNCjogSnVzdCBzb21lIGVhcmx5IG1vcm5p bmcgdGhvdWdodHMgOy0wDQo6IA0KOiBSDQo6IA0KOiA+DQo6ID4gSSB3b3VsZCBzdGlsbCBsaWtl IHRvIGNvbW1pdCB0aGlzIHNvIGFzIHRvIGtlZXAgbWFraW5nIHByb2dyZXNzIG9uIHRoZQ0KOiA+ IFNNUCBzdXBwb3J0LiBUaGlzIGlzIGEgc21hbGwgcGllY2Ugb2YgdGhlIGJpZ2dlciBnb2FsIG9m IGdldHRpbmcgU01QDQo6ID4gZnVuY3Rpb25hbCBhbmQgY2FuIGJlIHJlcGxhY2VkIGluIHRoZSBm dXR1cmUgaWYgbmVlZCBiZS4NCjogPg0KOiA+IGJlc3QNCjogPiBOZWVsDQo6ID4NCjogPiBPbiBU aHUsIEphbiAyOCwgMjAxMCBhdCAxMDo0MiBQTSwgSnVsaSBNYWxsZXR0IDxqbWFsbGV0dEBmcmVl YnNkLm9yZz4NCjogPiB3cm90ZToNCjogPj4gT24gVGh1LCBKYW4gMjgsIDIwMTAgYXQgMjE6Mjgs IFJhbmRhbGwgU3Rld2FydCA8cnJzQGxha2VyZXN0Lm5ldD4NCjogPj4gd3JvdGU6DQo6ID4+Pj4g WyBVc2luZyBhIHNpbmdsZSB3aXJlZCBUTEIgZW50cnkgZm9yIGtzdGFjayBhbmQgcGNwdSBdDQo6 ID4+Pg0KOiA+Pj4gV2hpY2ggbWVhbnMgeW91IGhhdmUgYSBiaWcgYXJyYXkgdGhhdCB5b3UgYXJl IG9mZnNldHRpbmcuDQo6ID4+DQo6ID4+IE5vdCByZWFsbHkg4oCUIHlvdSBjYW4gaGF2ZSBhIHN0 cnVjdHVyZSBhdCAweGMwMDAwMDAwMDAwMDAwMDB1IChvciB0aGUNCjogPj4gc2FtZSA+PiAzMikg d2l0aCB0d28gcG9pbnRlcnMgaW4gaXQsIGV2ZW4sIG9uZSB0byBwY3B1IGFuZCBvbmUgdG8NCjog Pj4gS1NUQUNLX1BBR0VTIGRpcmVjdC1tYXBwZWQsIGNvbnRpZ3VvdXMgcGFnZXMuICBUaGVuIHlv dSBjYW4gbG9hZCB0aGUNCjogPj4ga3N0YWNrIGFkZHJlc3Mgb3IgdGhlIHBjcHUgYmFzZSB2ZXJ5 IHF1aWNrbHkuICBPZiBjb3Vyc2UsIHlvdSBjYW4gZXZlbg0KOiA+PiBoYXZlIGEgc2luZ2xlIHdp cmVkIGVudHJ5IGNvbnNpc3Rpbmcgb2YgdGhlIHBjcHUgZGF0YSBhbmQgdGhlbiBwdXQgYQ0KOiA+ PiBwb2ludGVyIHRvIHRoZSB0b3Agb2YgdGhlIGtzdGFjayBpbiBpdC4gIEkgZG9uJ3QgdGhpbmsg eW91IGNhbiBnZXQgYnkNCjogPj4gd2l0aCBubyB3aXJlZCBUTEIgZW50cmllcywgYnV0IHlvdSBh bHNvIGRvbid0IGhhdmUgdG8gaW5kZXggYSBiaWcNCjogPj4gYXJyYXkuICBUaGUgbmljZSB0aGlu ZyBhYm91dCBzZXR0aW5nIHVwIGEgcGVyLUNQVSBUTEIgZW50cnkgKHlvdSBoYXZlDQo6ID4+IHRv IHNldCB1cCBhdCBsZWFzdCBvbmUsIHRoZSBrc3RhY2ssIGluIG9yZGVyIHRvIGJlIGFibGUgdG8g aGFuZGxlDQo6ID4+IGV4Y2VwdGlvbnMpIGlzIHRoYXQgdGhlbiB5b3UgbmVlZCBvbmx5IGFjY2Vz cyBvZmZzZXRzIGludG8gaXQgdGhhdCBhcmUNCjogPj4ga25vd24gYXQgY29tcGlsZSB0aW1lIGFu ZCBjb25zdGFudCBubyBtYXR0ZXIgd2hhdCBDUFUgeW91J3JlIHJ1bm5pbmcNCjogPj4gb24uICBM b2FkIHRoZSBrc3RhY2sgYnkgZG9pbmcgImxkIHNwLCAwKDB4Yy4uLikiIGFuZCBsb2FkIHRoZSBw Y3B1DQo6ID4+IGFkZHJlc3MgYnkgZG9pbmcgImxkIHQwLCA4KDB4Yy4uLi4pIi4gIFR3byB3aXJl ZCBlbnRyaWVzIGxldHMgeW91IGdldA0KOiA+PiByaWQgb2YgdGhlIGluZGlyZWN0aW9uLCBidXQg eW91IGNhbiBnZXQgYnkgd2l0aCBvbmUgYW5kIHN0aWxsIG5vdCBoYXZlDQo6ID4+IHRvIGRvICgx KSBydW4tdGltZSBjb21wdXRhdGlvbiBvZiB0aGUgaW5kZXggaW50byBzb21lIGFycmF5ICgyKQ0K OiA+PiBwb3NzaWJseSB2ZXJ5IGV4cGVuc2l2ZSBnZXR0aW5nIG9mIHRoZSBjcHVpZC4NCjogPj4N CjogPj4+IEkgd2FzIGV2ZW4gdGhpbmtpbmcgZ2V0IGEgTEFSR0UgZW50cnkuLiBvbmUgdGhhdCBp cyBzYXkgOCBNZWcNCjogPj4+IGZvciB0aGUga2VybmVsLi4gY292ZXJpbmcgYWxsIHRleHQvZGF0 YSBldGMuLi4gd2l0aCB0aGlzDQo6ID4+PiBuZXcgc3VwZXIgcGFnZSBzdHVmZi4gb2YgY291cnNl IEkgaGF2ZSBuZXZlciBsb29rZWQgaW50byBob3cNCjogPj4+IGl0cyBpbXBsZW1lbnRlZC4uDQo6 ID4+DQo6ID4+IFRoYXQgd291bGQgYmUgZWFzeSB0byBkbywgYnV0IHdoYXQgd291bGQgYmUgdGhl IGJlbmVmaXRzIG9mIGFjY2Vzc2luZw0KOiA+PiB0aGF0IGRhdGEgdGhyb3VnaCBhIHdpcmVkIFRM QiBlbnRyeSBpbnN0ZWFkIG9mIHRoZSBkaXJlY3QgbWFwPw0KOiA+Pg0KOiA+Pj4gWWVzLCB5b3Ug cGF5IGFuIGluZGV4IHJlZmVyZW5jZSBmb3IgZXZlcnkgYWNjZXNzIC4uIG9yIGF0DQo6ID4+PiBs ZWFzdCBvbmUgdG8gc2V0dXAgYSBwb2ludGVyLi4gYnV0IEkgdGhpbmsgdGhhdCBpdCBtdWNoIGNo ZWFwZXINCjogPj4+IHRoYW4gYSBUTEIgbWlzcyBpcy4uLiAod29yZHMgZm9yIGltcCB0byB0aGlu ayBhYm91dCkuLi4NCjogPj4NCjogPj4gWWVzLCBUTEIgbWlzc2VzIGFyZSB2ZXJ5IHNsb3cuICBZ b3VyIGRlc2lyZSB0byBhdm9pZCBhZGRpbmcgYW5vdGhlcg0KOiA+PiB3aXJlZCBlbnRyeSBzZWVt cyBwcmV0dHkgcmVhc29uYWJsZS4gIEkgdGhpbmsgdGhhdCB1c2luZyBhIHNpbmdsZQ0KOiA+PiB3 aXJlZCBUTEIgZW50cnkgZm9yIGEgbXV4IG9yIGZvciBib3RoIHRoZSBrc3RhY2sgYW5kIHBjcHUg aXMgZWFzeSBhbmQNCjogPj4gdXNhYmxlLiAgSSBmZWVsIGxpa2UganVzdCB3aXJpbmcgdGhlIGtz dGFjayBhbmQgcHV0dGluZyBhDQo6ID4+IGRpcmVjdC1tYXBwZWQsIHNvbWV0aW1lcy1yZWNvbXB1 dGVkIHBvaW50ZXIgdG8gdGhlIHBjcHUgaW50byBncCBpcyB0aGUNCjogPj4gYmVzdCBjb21iaW5h dGlvbiBpbiB0aGUgbG9uZyBydW4g4oCUIGV2ZW4ganVzdCBsb2FkaW5nIGFuIGltbWVkaWF0ZQ0K OiA+PiA2NC1iaXQgYWRkcmVzcyBpcyBwcmV0dHkgc2xvdyB3cnQgaG93IG9mdGVuIHRoaW5ncyBp biB0aGUgUENQVSBhcmUNCjogPj4gYWNjZXNzZWQgaW4gU01QIGtlcm5lbHMuDQo6ID4+DQo6ID4+ IEp1bGkuDQo6ID4+DQo6ID4NCjogDQo6IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0K OiBSYW5kYWxsIFN0ZXdhcnQNCjogODAzLTMxNy00OTUyIChjZWxsKQ0KOiA4MDMtMzQ1LTAzOTEo ZGlyZWN0KQ0KOiANCjogX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCjogZnJlZWJzZC1taXBzQGZyZWVic2Qub3JnIG1haWxpbmcgbGlzdA0KOiBodHRwOi8v bGlzdHMuZnJlZWJzZC5vcmcvbWFpbG1hbi9saXN0aW5mby9mcmVlYnNkLW1pcHMNCjogVG8gdW5z dWJzY3JpYmUsIHNlbmQgYW55IG1haWwgdG8NCjogImZyZWVic2QtbWlwcy11bnN1YnNjcmliZUBm cmVlYnNkLm9yZyINCjogDQo6IA0K From owner-freebsd-mips@FreeBSD.ORG Sat Jan 30 12:39:49 2010 Return-Path: Delivered-To: freebsd-mips@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 45A46106566C; Sat, 30 Jan 2010 12:39:49 +0000 (UTC) (envelope-from c.jayachandran@gmail.com) Received: from mail-pz0-f194.google.com (mail-pz0-f194.google.com [209.85.222.194]) by mx1.freebsd.org (Postfix) with ESMTP id 128048FC13; Sat, 30 Jan 2010 12:39:48 +0000 (UTC) Received: by pzk32 with SMTP id 32so92471pzk.27 for ; Sat, 30 Jan 2010 04:39:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=z+iao1q3Mpf3RIVXKDIiMOMB9I/tFoSTCZpmFoQdg3c=; b=oPFjJ0+Y6X6uj81wWgsd45NIjfVNUDgqRy1TNIoEBLMivB/dVroG8lL7512rDQ5f9s o3grdgY5HcUdAjHwxeR9HuG31gDgHcwdIs35vzAkOKAaPidJ7JKhBfY7qQIxjnX8RMbY rOkzeNbN6p9NI4PI627bx3/38I38jdlPL/lDk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=WtRwP3nEGDhcTACTV7qY4TG89iUcvMGONJKot2sR9mksF/VoTlzBo3ogvUtODvGhli uJiXM/BQWSizf2bMnS2apf6dkFDcYXuGcz3teAZSZ4Lw/dBg1+33s/lS41mf+9/cka3v QfGWA7gwBOtMbUG5K1fBNmAHOuYz3bxxwWpeA= MIME-Version: 1.0 Received: by 10.141.88.19 with SMTP id q19mr1449792rvl.89.1264855188540; Sat, 30 Jan 2010 04:39:48 -0800 (PST) In-Reply-To: <20100129.100052.1013538172663276257.imp@bsdimp.com> References: <85D9D383-29A3-4F09-A2FE-61E4EA85CE9B@lakerest.net> <20100129.100052.1013538172663276257.imp@bsdimp.com> Date: Sat, 30 Jan 2010 18:09:48 +0530 Message-ID: <98a59be81001300439o12ec3bf4pc5c03d4f1511297b@mail.gmail.com> From: "C. Jayachandran" To: "M. Warner Losh" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-mips@freebsd.org, neelnatu@gmail.com Subject: Re: Code review: groundwork for SMP X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Jan 2010 12:39:49 -0000 On Fri, Jan 29, 2010 at 10:30 PM, M. Warner Losh wrote: > Greetings one and all. =C2=A0Thanks for weighing in on this issue. > > In general, I agree with Neel here. =C2=A0But I also think we need to see > if we can be flexible and push this down into a per-cpu-type > decision (which differs slightly from a per-platform type because we > can have a CPU appearing in multiple platforms, or multiple CPUs > appearing within one platform). =C2=A0If we make it a per-cpu-type > solution, we could have a sys/mips/mips/pcpu_machdep.c which does the > normal SMP stuff, as well as having sys/mips/xlr/pcpu_machdep.c which > does something optimized for the XLR. =C2=A0Chances are good that differe= nt > CPUs will want to have different trade-offs here. =C2=A0We'd also need so= me > way to encode this in an include file, so there's some work to make > PCPU macro different for different CPUs... Yes, I think if the PCPU macros can be left to the specific implementation (even if that involves just ifdef in pcpu.h), we are fine. As I wrote earlier XLR preferred implementation would be to have the this in direct-mapped memory and have pointers in per-CPU scratch registers, and avoid TLB overhead. [...] > The XLR will have scheduler challenges as well. =C2=A0It will push the > design assumptions of ULE beyond the breaking point, I fear. > Hyperthreading already exists on intel, and ULE copes, a bit, with > it. =C2=A0But with the high number of threads each CPU can have, we may > need something with a little more smarts. =C2=A0Something that knows it > might be better to schedule two different processes on two different > cores, and leave some of the threads idle to reduce TLB pressure, for > example. Yes, this is one area we have not looked at much. > Per CPU scratch registers do not exist on MIPS, in general. =C2=A0Some CP= Us > have them, and many do not. =C2=A0CP0 registers are plentiful in more > modern designs, and some of them may even be useful for our needs. > However, mfc0 and mtc0 often have pipeline hazards associated with > them which will trip up the unwary. =C2=A0When reading the historical > errata for MIPS CPUs, we often find that this is where we need to do > the most workarounds. In XLR, there are 8 scratch registers, which can be accessed in a few cycles without any software visible hazards. So in our internal port we keep things like PCPU pointer and 'curthread' in scratch registers. > I guess this is a long way to say "I think we should commit Neel's > patches. =C2=A0We should work along two fronts: (1) implementing Juli's > idea of sharing kstack and pcpu data in one TLB and (2) making it so > that CPUs where this is sub-optimal can swap in their own > implementation." Another suggestion I have on Neel's implementation would be to allocate the pages (direct-mapped) at bootup, so that memory is not taken for cpus which are not available (XLR can have 4-32 cpus depending on the chip). Regards, JC.