From owner-freebsd-ppc@FreeBSD.ORG Sun Apr 13 09:37:35 2008 Return-Path: Delivered-To: powerpc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 84221106564A; Sun, 13 Apr 2008 09:37:35 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id 515E18FC12; Sun, 13 Apr 2008 09:37:35 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.14.2/8.14.2) with ESMTP id m3D9bYl6074766; Sun, 13 Apr 2008 05:37:34 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.14.2/8.14.2) with ESMTP id m3D9bYYw047540; Sun, 13 Apr 2008 05:37:34 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 367BD73039; Sun, 13 Apr 2008 05:37:34 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20080413093734.367BD73039@freebsd-current.sentex.ca> Date: Sun, 13 Apr 2008 05:37:34 -0400 (EDT) X-Virus-Scanned: ClamAV 0.92.1/6526/Tue Apr 1 08:33:51 2008 clamav-milter version 0.92.1 on clamscanner3 X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on powerpc/powerpc X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Apr 2008 09:37:35 -0000 TB --- 2008-04-13 08:28:11 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2008-04-13 08:28:11 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2008-04-13 08:28:11 - cleaning the object tree TB --- 2008-04-13 08:28:32 - cvsupping the source tree TB --- 2008-04-13 08:28:32 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/powerpc/powerpc/supfile TB --- 2008-04-13 08:28:39 - building world (CFLAGS=-O -pipe) TB --- 2008-04-13 08:28:39 - cd /src TB --- 2008-04-13 08:28:39 - /usr/bin/make -B buildworld >>> World build started on Sun Apr 13 08:28:41 UTC 2008 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Sun Apr 13 09:32:02 UTC 2008 TB --- 2008-04-13 09:32:02 - generating LINT kernel config TB --- 2008-04-13 09:32:02 - cd /src/sys/powerpc/conf TB --- 2008-04-13 09:32:02 - /usr/bin/make -B LINT TB --- 2008-04-13 09:32:02 - building LINT kernel (COPTFLAGS=) TB --- 2008-04-13 09:32:02 - cd /src TB --- 2008-04-13 09:32:02 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sun Apr 13 09:32:02 UTC 2008 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -ffreestanding -Werror /src/sys/net/radix_mpath.c cc -c -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -ffreestanding -Werror /src/sys/net/raw_cb.c cc -c -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -ffreestanding -Werror /src/sys/net/raw_usrreq.c cc -c -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -ffreestanding -Werror /src/sys/net/route.c cc1: warnings being treated as errors /src/sys/net/route.c: In function 'rtrequest1': /src/sys/net/route.c:809: warning: label 'deldone' defined but not used /src/sys/net/route.c:768: warning: label 'normal_rtdel' defined but not used *** Error code 1 Stop in /obj/powerpc/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-04-13 09:37:34 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-04-13 09:37:34 - ERROR: failed to build lint kernel TB --- 2008-04-13 09:37:34 - tinderbox aborted TB --- 3066.45 user 363.85 system 4162.33 real http://tinderbox.des.no/tinderbox-head-HEAD-powerpc-powerpc.full From owner-freebsd-ppc@FreeBSD.ORG Mon Apr 14 11:06:54 2008 Return-Path: Delivered-To: freebsd-ppc@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AE98B106564A for ; Mon, 14 Apr 2008 11:06:54 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 9E3258FC1C for ; Mon, 14 Apr 2008 11:06:54 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m3EB6swK072331 for ; Mon, 14 Apr 2008 11:06:54 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m3EB6sKN072327 for freebsd-ppc@FreeBSD.org; Mon, 14 Apr 2008 11:06:54 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 14 Apr 2008 11:06:54 GMT Message-Id: <200804141106.m3EB6sKN072327@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-ppc@FreeBSD.org Cc: Subject: Current problem reports assigned to freebsd-ppc@FreeBSD.org X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Apr 2008 11:06:54 -0000 Current FreeBSD problem reports Critical problems Serious problems S Tracker Resp. Description -------------------------------------------------------------------------------- o power/93203 ppc FreeBSD PPC Can't Write to Partitions. f power/121407 ppc [panic] Won't boot up; strange error message. 2 problems total. Non-critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- o power/111296 ppc [kernel] [patch] [request] Support IMISS, DLMISS an DS o power/112435 ppc [nexus] [patch] Update nexus children to use ofw_bus f 2 problems total. From owner-freebsd-ppc@FreeBSD.ORG Mon Apr 14 17:34:42 2008 Return-Path: Delivered-To: freebsd-ppc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9E3EC1065675 for ; Mon, 14 Apr 2008 17:34:42 +0000 (UTC) (envelope-from info@uktradestreet.com) Received: from smtp5.freeserve.com (smtp5.freeserve.com [193.252.22.159]) by mx1.freebsd.org (Postfix) with ESMTP id 35EFE8FC13 for ; Mon, 14 Apr 2008 17:34:42 +0000 (UTC) (envelope-from info@uktradestreet.com) Received: from smtp5.freeserve.com (mwinf3423 [10.232.11.123]) by mwinf3415.me.freeserve.com (SMTP Server) with ESMTP id 534A31C00F2A for ; Mon, 14 Apr 2008 19:14:29 +0200 (CEST) Received: from me-wanadoo.net (localhost [127.0.0.1]) by mwinf3423.me.freeserve.com (SMTP Server) with ESMTP id 40B8E1C00086 for ; Mon, 14 Apr 2008 19:14:29 +0200 (CEST) Received: from Tilly (unknown [91.104.80.190]) by mwinf3423.me.freeserve.com (SMTP Server) with SMTP id 123BC1C0008F for ; Mon, 14 Apr 2008 19:14:24 +0200 (CEST) X-ME-UUID: 20080414171424750.123BC1C0008F@mwinf3423.me.freeserve.com Message-ID: <717554840041e1a1b0d9d01c001fc485@uktradestreet.com> From: "uktradestreet" To: Date: Mon, 14 Apr 2008 17:59:48 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Renovation Projects X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: info@uktradestreet.com List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Apr 2008 17:34:42 -0000 Hello I came across your details=A0and hope you will not see this as junk mail; = if=20 so, please do accept my apologies=2E =A0 We at =A0www.uktradestreet.com=A0 can offer you a complimentary service in = that=20 we have genuine customers - both commercial and domestic who would need = your=20 services and as such we would welcome you to register with us for FREE=2E =A0 If you are a customer who needs to have a job undertaken - whether at = home=20 or in the office, then likewise you are most welcome to post your job on = our=20 site, and honest, reliable and customer recommended = Tradespeople/companies,=20 will be happy to give you=A0a Quotation=2E =A0 Why not have a look around, and remember, it is FREE to register ~ and = you=20 can tell all your friends and colleagues too! =A0 Thanks Michelle T:020 8133 0625 www.uktradestreet.com =A0 =A0 To unsubscribe please reply with 'unsubscribe' in subject heading ~ but = we hope you will sign up first! From owner-freebsd-ppc@FreeBSD.ORG Tue Apr 15 13:26:21 2008 Return-Path: Delivered-To: freebsd-ppc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 509BD106566C for ; Tue, 15 Apr 2008 13:26:21 +0000 (UTC) (envelope-from nathanw@uchicago.edu) Received: from agogare.doit.wisc.edu (agogare.doit.wisc.edu [144.92.197.211]) by mx1.freebsd.org (Postfix) with ESMTP id 264B18FC17 for ; Tue, 15 Apr 2008 13:26:21 +0000 (UTC) (envelope-from nathanw@uchicago.edu) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=ISO-8859-1; format=flowed Received: from avs-daemon.smtpauth2.wiscmail.wisc.edu by smtpauth2.wiscmail.wisc.edu (Sun Java(tm) System Messaging Server 6.3-5.02 (built Oct 12 2007; 32bit)) id <0JZD00B00BZWV900@smtpauth2.wiscmail.wisc.edu> for freebsd-ppc@freebsd.org; Tue, 15 Apr 2008 08:26:20 -0500 (CDT) Received: from trantor.tachypleus.net ([76.201.159.245]) by smtpauth2.wiscmail.wisc.edu (Sun Java(tm) System Messaging Server 6.3-5.02 (built Oct 12 2007; 32bit)) with ESMTPSA id <0JZD00AFWBZVHK10@smtpauth2.wiscmail.wisc.edu> for freebsd-ppc@freebsd.org; Tue, 15 Apr 2008 08:26:19 -0500 (CDT) Date: Tue, 15 Apr 2008 08:30:59 -0500 From: Nathan Whitehorn To: freebsd-ppc@freebsd.org Message-id: <4804AE13.2060600@uchicago.edu> X-Spam-Report: AuthenticatedSender=yes, SenderIP=76.201.159.245 X-Spam-PmxInfo: Server=avs-11, Version=5.4.1.325704, Antispam-Engine: 2.6.0.325393, Antispam-Data: 2008.4.15.60825, SenderIP=76.201.159.245 User-Agent: Thunderbird 2.0.0.12 (X11/20080322) Subject: G5 Bridge-mode MMU X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Apr 2008 13:26:21 -0000 I'm trying to get G5 support going, and have run into an interesting problem while bootstrapping the MMU. Firmware loads the kernel in protected mode, and we have no BAT facility. Thus, the bootstrap allocator fails because low physical memory isn't 1:1 mapped. And we can't add this region to the page table, because the page table is what we are trying to allocate. And we can't even use the MMU's large page facility in bridge mode. One solution is to drop back to data real mode while the page table is allocated and set up. This seems to work ok, but requires that the kernel stack is mapped 1:1, which seems to be the case on my iMac G5. I'm not sure how reliable this assumption is, though. It's also irritating because any open firmware calls from real mode (e.g. printf()) make the machine hang up. The other solution is to prepare a temporary statically-allocated page table with enough mappings to map the kernel, OF, and the real page table, then switch to the dynamically allocated one. I'm not sure there is enough stack for this though, since we are so early in the boot process. It could be globally statically allocated, but that would pointlessly increase the kernel memory footprint of everyone with bridge support compiled into their kernels. Thoughts? -Nathan From owner-freebsd-ppc@FreeBSD.ORG Tue Apr 15 15:30:56 2008 Return-Path: Delivered-To: freebsd-ppc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1FB9A106564A for ; Tue, 15 Apr 2008 15:30:56 +0000 (UTC) (envelope-from grehan@freebsd.org) Received: from alto.onthenet.com.au (alto.OntheNet.com.au [203.13.68.12]) by mx1.freebsd.org (Postfix) with ESMTP id 9C5A38FC1D for ; Tue, 15 Apr 2008 15:30:55 +0000 (UTC) (envelope-from grehan@freebsd.org) Received: from dommail.onthenet.com.au (dommail.OntheNet.com.au [203.13.70.57]) by alto.onthenet.com.au (Postfix) with ESMTP id D043212570; Wed, 16 Apr 2008 01:29:47 +1000 (EST) Received: from peter-grehans-power-mac-g5.local (dsl-63-249-90-35.cruzio.com [63.249.90.35]) by dommail.onthenet.com.au (MOS 3.7.5a-GA) with ESMTP id DVW67417 (AUTH peterg@ptree32.com.au); Wed, 16 Apr 2008 01:29:47 +1000 (EST) Message-ID: <4804C9E9.6010303@freebsd.org> Date: Tue, 15 Apr 2008 08:29:45 -0700 From: Peter Grehan User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) MIME-Version: 1.0 To: Nathan Whitehorn References: <4804AE13.2060600@uchicago.edu> In-Reply-To: <4804AE13.2060600@uchicago.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-ppc@freebsd.org Subject: Re: G5 Bridge-mode MMU X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: grehan@freebsd.org List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Apr 2008 15:30:56 -0000 Hi Nathan, Great to see you taking on this work ! > I'm trying to get G5 support going, and have run into an interesting > problem while bootstrapping the MMU. Firmware loads the kernel in > protected mode, and we have no BAT facility. Thus, the bootstrap > allocator fails because low physical memory isn't 1:1 mapped. And we > can't add this region to the page table, because the page table is what > we are trying to allocate. And we can't even use the MMU's large page > facility in bridge mode. You really can't use the existing MMU code. The G5 was the driving factor to create the pmap indirection. My thoughts were to abandon the existing method of trying to keep the OFW mappings the same as the kernel mappings, and completely switch address spaces when calling back into OFW, rather than just changing segment registers. This would require an indirection in the OFW code to jumpto to a routine that switches stacks, but code similar to that already exists in NetBSD for older G3's where OFW runs in real-mode. > One solution is to drop back to data real mode while the page table is > allocated and set up. This seems to work ok, but requires that the > kernel stack is mapped 1:1, which seems to be the case on my iMac G5. > I'm not sure how reliable this assumption is, though. It's also > irritating because any open firmware calls from real mode (e.g. > printf()) make the machine hang up. It's a good enough assumption to make in pmap_bootstrap(). Calls to OFW usually copy the parameters into BSS, though there are some that don't. > The other solution is to prepare a temporary statically-allocated page > table with enough mappings to map the kernel, OF, and the real page > table, then switch to the dynamically allocated one. I think you want to allocate the real page table, put enough mappings in there for the kernel text+data+bss (and the frame buffer if that is being used for the console) and the page table itself, and modify OFW so that there is a big context switch when calling into it. Use the existing call into OFW to get it's mappings to make sure those pages are excluded from kernel use. There are some other gotchas that you may know about: - the OFW calls to determine the amount of memory don't use two cells for addresses, required on a G5. That's a simple fix (which you might already have :). You might wonder why I did that work for the loader and never submitted it for the kernel :) Memory should be restricted to <= 4G. There's no need for a PAE-style mode to get more memory. Instead, that should be the target of a true 64-bit PPC port. - interrupts switch the CPU to 64-bit mode. You have to immediately drop to 32-bit mode in the interrupt handler before any branch is taken. My plan was to have a macro in the exception asm that did this, and also expanded to 'rfid' for the return. The asm would then be included into trap_subr.S and expanded to 32/64-bit, in a similar fashion to how the kernel does elf32 and elf64 via macro expansion. Installing the vectors would also then become CPU-model specific, but that was inevitable to support other CPU models with different vector requirements. - the G3/4 pmap code relies on 1:1 BAT mapping for page-zeroing. The G5 code will have to use an i386-style temporary mapping for this. - another 1:1 relic is the use of UMA_MD_SMALL_ALLOC. I talked with Alan Cox a long time back about being able to dynamically determine whether this could be used, though that is a fair amount of work. I would like to see a single kernel for G3/4/5, but that may be asking too much up front, especially given my lack of progress in achieving this goal :) - the G5 uses two cascaded OpenPIC interrupt controllers. The interrupt code needs to be reworked to support this concept. .. and probably many more. later, Peter. From owner-freebsd-ppc@FreeBSD.ORG Tue Apr 15 16:32:37 2008 Return-Path: Delivered-To: freebsd-ppc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6665A106566C; Tue, 15 Apr 2008 16:32:37 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from smtpoutm.mac.com (smtpoutm.mac.com [17.148.16.78]) by mx1.freebsd.org (Postfix) with ESMTP id 4DAC88FC23; Tue, 15 Apr 2008 16:32:37 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from mac.com (asmtp005-s [10.150.69.68]) by smtpoutm.mac.com (Xserve/smtpout015/MantshX 4.0) with ESMTP id m3FGWbuS024327; Tue, 15 Apr 2008 09:32:37 -0700 (PDT) Received: from macbook-pro.jnpr.net (natint3.juniper.net [66.129.224.36]) (authenticated bits=0) by mac.com (Xserve/asmtp005/MantshX 4.0) with ESMTP id m3FGWCuv023419 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 15 Apr 2008 09:32:17 -0700 (PDT) Message-Id: <5CC81F06-7B59-4163-9AB8-2ACE4235A5AA@mac.com> From: Marcel Moolenaar To: grehan@freebsd.org In-Reply-To: <4804C9E9.6010303@freebsd.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v919.2) Date: Tue, 15 Apr 2008 09:32:11 -0700 References: <4804AE13.2060600@uchicago.edu> <4804C9E9.6010303@freebsd.org> X-Mailer: Apple Mail (2.919.2) Cc: freebsd-ppc@freebsd.org Subject: Re: G5 Bridge-mode MMU X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Apr 2008 16:32:37 -0000 On Apr 15, 2008, at 8:29 AM, Peter Grehan wrote: > - the G5 uses two cascaded OpenPIC interrupt controllers. The > interrupt code needs to be reworked to support this concept. Have the beginnings of that. Not generically enough for cascaded OpenPICs, but close enough that I should be able to get it right for 90% or so... There's a bigger problem though: the current AIM pmap code and exception handling is broken for kernel stacks. The problem is that it is assumed by the exception code that the whole stack is mapped and DSI traps for the stack are assumed to be stack over- runs. If we ever need more than 1 page of kernel stack, we're hosed. The good thing is that we now that we can safely reduce the kernel stack to 2 pages, but the bad thing is that we need to handle nested DSI traps or actually make sure the kernel stack is always mapped. Also, with process address space limited to 2G, I wonder why we keep swapping all segment registers and not just the lower 8? Related: how hard would it be to map the kernel above 2G and eliminate the SR swap in the exception handlers (but do it on context switches)? -- Marcel Moolenaar xcllnt@mac.com From owner-freebsd-ppc@FreeBSD.ORG Tue Apr 15 16:51:29 2008 Return-Path: Delivered-To: freebsd-ppc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E5D1A1065671 for ; Tue, 15 Apr 2008 16:51:29 +0000 (UTC) (envelope-from grehan@freebsd.org) Received: from alto.onthenet.com.au (alto.OntheNet.com.au [203.13.68.12]) by mx1.freebsd.org (Postfix) with ESMTP id A1D0C8FC22 for ; Tue, 15 Apr 2008 16:51:29 +0000 (UTC) (envelope-from grehan@freebsd.org) Received: from dommail.onthenet.com.au (dommail.OntheNet.com.au [203.13.70.57]) by alto.onthenet.com.au (Postfix) with ESMTP id 46001120E1; Wed, 16 Apr 2008 02:51:25 +1000 (EST) Received: from peter-grehans-power-mac-g5.local (dsl-63-249-90-35.cruzio.com [63.249.90.35]) by dommail.onthenet.com.au (MOS 3.7.5a-GA) with ESMTP id DVX13406 (AUTH peterg@ptree32.com.au); Wed, 16 Apr 2008 02:51:25 +1000 (EST) Message-ID: <4804DD02.10304@freebsd.org> Date: Tue, 15 Apr 2008 09:51:14 -0700 From: Peter Grehan User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) MIME-Version: 1.0 To: Marcel Moolenaar References: <4804AE13.2060600@uchicago.edu> <4804C9E9.6010303@freebsd.org> <5CC81F06-7B59-4163-9AB8-2ACE4235A5AA@mac.com> In-Reply-To: <5CC81F06-7B59-4163-9AB8-2ACE4235A5AA@mac.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-ppc@freebsd.org Subject: Re: G5 Bridge-mode MMU X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: grehan@freebsd.org List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Apr 2008 16:51:30 -0000 Hi Marcel, > There's a bigger problem though: the current AIM pmap code and > exception handling is broken for kernel stacks. I've not seen any evidence of this. Granted, I've only tested with psim, but I can safely access all of kstack0's virtual address space. All of the stack pages are wired, as are the mappings. Where are the DSI exceptions occurring ? Stack *overflow* exception handling may be busted, but that is a challenging problem to get right. > Also, with process address space limited to 2G Where's that limitation ? If so, that's a bug: it should be 4G. > I wonder why we > keep swapping all segment registers and not just the lower 8? As above. That was taken from NetBSD to give the full 4G address space for users. It used to be the high 8 seg regs, since the lower 2G was either 1:1 BAT-mapped memory or PCI mem space. > Related: how hard would it be to map the kernel above 2G and > eliminate the SR swap in the exception handlers (but do it on > context switches)? You would have to eliminate the 1:1 mapping. I know this was done in the bookE port, and it is painful to have two kernel ABIs. How about the corollary: how hard is it to get the bookE port to use a separate address space for the kernel ? later, Peter. From owner-freebsd-ppc@FreeBSD.ORG Tue Apr 15 17:40:14 2008 Return-Path: Delivered-To: freebsd-ppc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1FC341065673; Tue, 15 Apr 2008 17:40:14 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from smtpoutm.mac.com (smtpoutm.mac.com [17.148.16.78]) by mx1.freebsd.org (Postfix) with ESMTP id 05C8D8FC23; Tue, 15 Apr 2008 17:40:13 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from mac.com (asmtp006-s [10.150.69.69]) by smtpoutm.mac.com (Xserve/smtpout015/MantshX 4.0) with ESMTP id m3FHeDii026798; Tue, 15 Apr 2008 10:40:13 -0700 (PDT) Received: from macbook-pro.jnpr.net (natint3.juniper.net [66.129.224.36]) (authenticated bits=0) by mac.com (Xserve/asmtp006/MantshX 4.0) with ESMTP id m3FHe8hD018576 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 15 Apr 2008 10:40:09 -0700 (PDT) Message-Id: <058EEFE3-09D7-447A-93AB-3E90EC59ECDC@mac.com> From: Marcel Moolenaar To: grehan@freebsd.org In-Reply-To: <4804DD02.10304@freebsd.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v919.2) Date: Tue, 15 Apr 2008 10:40:03 -0700 References: <4804AE13.2060600@uchicago.edu> <4804C9E9.6010303@freebsd.org> <5CC81F06-7B59-4163-9AB8-2ACE4235A5AA@mac.com> <4804DD02.10304@freebsd.org> X-Mailer: Apple Mail (2.919.2) Cc: freebsd-ppc@freebsd.org Subject: Re: kernel stacks [eas: Re: G5 Bridge-mode MMU] X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Apr 2008 17:40:14 -0000 On Apr 15, 2008, at 9:51 AM, Peter Grehan wrote: > Hi Marcel, > >> There's a bigger problem though: the current AIM pmap code and >> exception handling is broken for kernel stacks. > > I've not seen any evidence of this. Granted, I've only tested with > psim, but I can safely access all of kstack0's virtual address > space. All of the stack pages are wired, as are the mappings. Where > are the DSI exceptions occurring ? Bus enumeration: usbd_new_device() is a known kernel stack hog. On my xserve the call-chain is deep enough that during bus-enumeration we actually run into the second kernel stack page. With the current implementation, this happens to be kstack0 and as such BAT-mapped. When we switch to the kernel stack allocated for thread0 (by pmap_bootstrap()) before we call mi_startup(), bus enumeration fails, because the second page happens to not be mapped - the not mapping means that the CPU couldn't find the translation in its TLB nor in the hash table. The exception code treats this as a kernel stack overflow. Another example is: if we get an interrupt while in kernel mode and the stack has been used enough that the trapframe crosses the page boundary, then we can get a page fault while constructing the trapframe. > Stack *overflow* exception handling may be busted, but that is a > challenging problem to get right. The logic currently assumes that there's never a DSI trap for the kernel stack. This simply is an invalid assumption. >> Also, with process address space limited to 2G > > Where's that limitation ? If so, that's a bug: it should be 4G. vmparam.h: #define VM_MAXUSER_ADDRESS 0x7ffff000 >> Related: how hard would it be to map the kernel above 2G and >> eliminate the SR swap in the exception handlers (but do it on >> context switches)? > > You would have to eliminate the 1:1 mapping. I know this was done in > the bookE port, and it is painful to have two kernel ABIs. > > How about the corollary: how hard is it to get the bookE port to use > a separate address space for the kernel ? Probably not too hard. We (i.e. Juniper) discussed this with Semihalf and for Juniper the single address space implementation was better, even though Semihalf started with the split address space. It makes sense to unify... I'll investigate... -- Marcel Moolenaar xcllnt@mac.com From owner-freebsd-ppc@FreeBSD.ORG Tue Apr 15 17:58:23 2008 Return-Path: Delivered-To: freebsd-ppc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C972E1065671; Tue, 15 Apr 2008 17:58:23 +0000 (UTC) (envelope-from nathanw@uchicago.edu) Received: from agogare.doit.wisc.edu (agogare.doit.wisc.edu [144.92.197.211]) by mx1.freebsd.org (Postfix) with ESMTP id 9C73B8FC13; Tue, 15 Apr 2008 17:58:23 +0000 (UTC) (envelope-from nathanw@uchicago.edu) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=ISO-8859-1; format=flowed Received: from avs-daemon.smtpauth2.wiscmail.wisc.edu by smtpauth2.wiscmail.wisc.edu (Sun Java(tm) System Messaging Server 6.3-5.02 (built Oct 12 2007; 32bit)) id <0JZD00000OLB4R00@smtpauth2.wiscmail.wisc.edu>; Tue, 15 Apr 2008 12:58:23 -0500 (CDT) Received: from [72.33.107.250] (dyn-107-250.uwnet.wisc.edu [72.33.107.250]) by smtpauth2.wiscmail.wisc.edu (Sun Java(tm) System Messaging Server 6.3-5.02 (built Oct 12 2007; 32bit)) with ESMTPSA id <0JZD00G3VOL6H170@smtpauth2.wiscmail.wisc.edu>; Tue, 15 Apr 2008 12:58:19 -0500 (CDT) Date: Tue, 15 Apr 2008 12:58:18 -0500 From: Nathan Whitehorn In-reply-to: <4804C9E9.6010303@freebsd.org> To: grehan@freebsd.org Message-id: <4804ECBA.5030905@uchicago.edu> X-Spam-Report: AuthenticatedSender=yes, SenderIP=72.33.107.250 X-Spam-PmxInfo: Server=avs-7, Version=5.4.1.325704, Antispam-Engine: 2.6.0.325393, Antispam-Data: 2008.4.15.104238, SenderIP=72.33.107.250 References: <4804AE13.2060600@uchicago.edu> <4804C9E9.6010303@freebsd.org> User-Agent: Thunderbird 1.5.0.12 (X11/20080213) Cc: freebsd-ppc@freebsd.org Subject: Re: G5 Bridge-mode MMU X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Apr 2008 17:58:23 -0000 Peter Grehan wrote: > Hi Nathan, > > Great to see you taking on this work ! > >> I'm trying to get G5 support going, and have run into an interesting >> problem while bootstrapping the MMU. Firmware loads the kernel in >> protected mode, and we have no BAT facility. Thus, the bootstrap >> allocator fails because low physical memory isn't 1:1 mapped. And we >> can't add this region to the page table, because the page table is >> what we are trying to allocate. And we can't even use the MMU's large >> page facility in bridge mode. > > You really can't use the existing MMU code. The G5 was the driving > factor to create the pmap indirection. Yeah, the bridge mode MMU is just different enough to be annoying. I'm using the existing code as a base, because (a) it's nice to have a template, and (b) most of the PTE handling stuff can be reused with s/struct pte/struct lpte and s/PTE/LPTE, and some changes to the hash function and PTE_EXEC bits. > My thoughts were to abandon the existing method of trying to keep the > OFW mappings the same as the kernel mappings, and completely switch > address spaces when calling back into OFW, rather than just changing > segment registers. This would require an indirection in the OFW code > to jumpto to a routine that switches stacks, but code similar to that > already exists in NetBSD for older G3's where OFW runs in real-mode. So you suggest saving OF's SDR1 and restoring it when we need to call in? I guess this would solve part of the problem (debugging output while initializing the MMU), but I'm sure sure I understand the real benefit to this. >> One solution is to drop back to data real mode while the page table >> is allocated and set up. This seems to work ok, but requires that the >> kernel stack is mapped 1:1, which seems to be the case on my iMac G5. >> I'm not sure how reliable this assumption is, though. It's also >> irritating because any open firmware calls from real mode (e.g. >> printf()) make the machine hang up. > > It's a good enough assumption to make in pmap_bootstrap(). Calls to > OFW usually copy the parameters into BSS, though there are some that > don't. OK. So it should be generally true that all the local variables and statically allocated things in pmap_bootstrap() should have virtual addresses equal to their physical address? If that is true then a brief trip to real mode seems to be the best option. >> The other solution is to prepare a temporary statically-allocated >> page table with enough mappings to map the kernel, OF, and the real >> page table, then switch to the dynamically allocated one. > > I think you want to allocate the real page table, put enough mappings > in there for the kernel text+data+bss (and the frame buffer if that is > being used for the console) and the page table itself, and modify OFW > so that there is a big context switch when calling into it. Use the > existing call into OFW to get it's mappings to make sure those pages > are excluded from kernel use. This isn't the real problem. The real problem is that we don't have the 1:1 BAT mapping, so you can't allocate memory (e.g. for the page table) without putting entries for it in the page table. Which you don't have yet. So you can either have a little, static page table that you can set up first or drop to real mode whenever you need to use dynamically allocated memory before the MMU is up. In the first case, you need to put 256 KB of page table on the stack, or globally allocate it, which means you've wasted a big chunk of memory that you will never need again and I'm not even sure there is that much stack available. In the second, if the rest of the kernel isn't 1:1 mapped, everything will instantly break. Also, going to real mode seems like kind of a hack, but I think it may be the best choice. It is also what OS X does. > There are some other gotchas that you may know about: > > - the OFW calls to determine the amount of memory don't use two cells > for addresses, required on a G5. That's a simple fix (which you might > already have :). You might wonder why I did that work for the loader > and never submitted it for the kernel :) Memory should be restricted > to <= 4G. There's no need for a PAE-style mode to get more memory. > Instead, that should be the target of a true 64-bit PPC port. Yeah, I put that in already, and not planning on going anywhere near a PAE-type mechanism. > - interrupts switch the CPU to 64-bit mode. You have to immediately > drop to 32-bit mode in the interrupt handler before any branch is > taken. My plan was to have a macro in the exception asm that did this, > and also expanded to 'rfid' for the return. The asm would then be > included into trap_subr.S and expanded to 32/64-bit, in a similar > fashion to how the kernel does elf32 and elf64 via macro expansion. > Installing the vectors would also then become CPU-model specific, but > that was inevitable to support other CPU models with different vector > requirements. This is kind of annoying. I haven't really thought about how best to handle it. Something to handle once the MMU is set up. > - the G3/4 pmap code relies on 1:1 BAT mapping for page-zeroing. The > G5 code will have to use an i386-style temporary mapping for this. Right. It looks like /dev/mem needs the BAT mapping too, along with a few other things. > - another 1:1 relic is the use of UMA_MD_SMALL_ALLOC. I talked with > Alan Cox a long time back about being able to dynamically determine > whether this could be used, though that is a fair amount of work. I > would like to see a single kernel for G3/4/5, but that may be asking > too much up front, especially given my lack of progress in achieving > this goal :) Well, once we have the page table set up, we can add a 1:1 mapping in certain places -- e.g. low memory -- by adding in a whole bunch of 4 KB pages. > - the G5 uses two cascaded OpenPIC interrupt controllers. The > interrupt code needs to be reworked to support this concept. This also goes on the list of things to worry about after I've seen the FreeBSD copyright notice... -Nathan From owner-freebsd-ppc@FreeBSD.ORG Tue Apr 15 18:15:34 2008 Return-Path: Delivered-To: freebsd-ppc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A201B106566B; Tue, 15 Apr 2008 18:15:34 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from smtpoutm.mac.com (smtpoutm.mac.com [17.148.16.79]) by mx1.freebsd.org (Postfix) with ESMTP id 869B38FC24; Tue, 15 Apr 2008 18:15:34 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from mac.com (asmtp007-s [10.150.69.70]) by smtpoutm.mac.com (Xserve/smtpout016/MantshX 4.0) with ESMTP id m3FIFXhp003777; Tue, 15 Apr 2008 11:15:33 -0700 (PDT) Received: from macbook-pro.jnpr.net (natint3.juniper.net [66.129.224.36]) (authenticated bits=0) by mac.com (Xserve/asmtp007/MantshX 4.0) with ESMTP id m3FIFSi2017075 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 15 Apr 2008 11:15:29 -0700 (PDT) Message-Id: <4454B9C3-77FF-489B-AF14-679D66FD2DED@mac.com> From: Marcel Moolenaar To: Rafal Jaworowski In-Reply-To: <4804ED17.3070907@semihalf.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v919.2) Date: Tue, 15 Apr 2008 11:15:22 -0700 References: <4804AE13.2060600@uchicago.edu> <4804C9E9.6010303@freebsd.org> <5CC81F06-7B59-4163-9AB8-2ACE4235A5AA@mac.com> <4804DD02.10304@freebsd.org> <058EEFE3-09D7-447A-93AB-3E90EC59ECDC@mac.com> <4804ED17.3070907@semihalf.com> X-Mailer: Apple Mail (2.919.2) Cc: grehan@freebsd.org, freebsd-ppc@freebsd.org Subject: Re: kernel stacks [eas: Re: G5 Bridge-mode MMU] X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Apr 2008 18:15:34 -0000 On Apr 15, 2008, at 10:59 AM, Rafal Jaworowski wrote: > Marcel Moolenaar wrote: >>>> Related: how hard would it be to map the kernel above 2G and >>>> eliminate the SR swap in the exception handlers (but do it on >>>> context switches)? >>> >>> You would have to eliminate the 1:1 mapping. I know this was done in >>> the bookE port, and it is painful to have two kernel ABIs. >>> >>> How about the corollary: how hard is it to get the bookE port to >>> use a >>> separate address space for the kernel ? >> >> Probably not too hard. >> >> We (i.e. Juniper) discussed this with Semihalf and for Juniper the >> single address space implementation was better, even though Semihalf >> started with the split address space. > > Yeah, in the original design we considered separate address spaces, > but after > discussions we went for the single AS, which apparently is simpler > and cheaper > (no need for any additional temporary mappings in copyin/out, > exceptions and > similar), but imposes limitations on the I/O ranges and KVA. So > maybe with the > upcoming more powerful BookE systems, with lots of RAM etc. it would > be time > for re-considering this, but I don't have any code from back then as > the idea > died pretty quickly, before main development happened. It would be great if we could support both -- not at runtime, but have it compile-time selectable. PowerPC does cover the embedded, desktop and server space so the needs are much more varied than for other platforms. I don't see any immediate consequence for our user-space ABI, so it may not be visible to user space (other than having the stack start at 4GB or so)... -- Marcel Moolenaar xcllnt@mac.com From owner-freebsd-ppc@FreeBSD.ORG Tue Apr 15 18:30:22 2008 Return-Path: Delivered-To: freebsd-ppc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 54DA21065673; Tue, 15 Apr 2008 18:30:22 +0000 (UTC) (envelope-from raj@semihalf.com) Received: from semihalf.com (semihalf.com [206.130.101.55]) by mx1.freebsd.org (Postfix) with ESMTP id A38698FC19; Tue, 15 Apr 2008 18:30:21 +0000 (UTC) (envelope-from raj@semihalf.com) Received: from mail.semihalf.com (mail.semihalf.com [83.15.139.206]) by semihalf.com (8.13.1/8.13.1) with ESMTP id m3FHxrDW016833; Tue, 15 Apr 2008 11:59:54 -0600 Message-ID: <4804ED17.3070907@semihalf.com> Date: Tue, 15 Apr 2008 19:59:51 +0200 From: Rafal Jaworowski MIME-Version: 1.0 To: Marcel Moolenaar References: <4804AE13.2060600@uchicago.edu> <4804C9E9.6010303@freebsd.org> <5CC81F06-7B59-4163-9AB8-2ACE4235A5AA@mac.com> <4804DD02.10304@freebsd.org> <058EEFE3-09D7-447A-93AB-3E90EC59ECDC@mac.com> In-Reply-To: <058EEFE3-09D7-447A-93AB-3E90EC59ECDC@mac.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: grehan@freebsd.org, freebsd-ppc@freebsd.org Subject: Re: kernel stacks [eas: Re: G5 Bridge-mode MMU] X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Apr 2008 18:30:22 -0000 Marcel Moolenaar wrote: >>> Related: how hard would it be to map the kernel above 2G and >>> eliminate the SR swap in the exception handlers (but do it on >>> context switches)? >> >> You would have to eliminate the 1:1 mapping. I know this was done in >> the bookE port, and it is painful to have two kernel ABIs. >> >> How about the corollary: how hard is it to get the bookE port to use a >> separate address space for the kernel ? > > Probably not too hard. > > We (i.e. Juniper) discussed this with Semihalf and for Juniper the > single address space implementation was better, even though Semihalf > started with the split address space. Yeah, in the original design we considered separate address spaces, but after discussions we went for the single AS, which apparently is simpler and cheaper (no need for any additional temporary mappings in copyin/out, exceptions and similar), but imposes limitations on the I/O ranges and KVA. So maybe with the upcoming more powerful BookE systems, with lots of RAM etc. it would be time for re-considering this, but I don't have any code from back then as the idea died pretty quickly, before main development happened. Rafal From owner-freebsd-ppc@FreeBSD.ORG Tue Apr 15 20:28:27 2008 Return-Path: Delivered-To: freebsd-ppc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3DEFD1065671 for ; Tue, 15 Apr 2008 20:28:27 +0000 (UTC) (envelope-from grehan@freebsd.org) Received: from alto.onthenet.com.au (alto.OntheNet.com.au [203.13.68.12]) by mx1.freebsd.org (Postfix) with ESMTP id F01138FC15 for ; Tue, 15 Apr 2008 20:28:26 +0000 (UTC) (envelope-from grehan@freebsd.org) Received: from dommail.onthenet.com.au (dommail.OntheNet.com.au [203.13.70.57]) by alto.onthenet.com.au (Postfix) with ESMTP id B5393122D7; Wed, 16 Apr 2008 06:28:22 +1000 (EST) Received: from excfreebsd.hq.netapp.com (nat-198-95-226-228.netapp.com [198.95.226.228]) by dommail.onthenet.com.au (MOS 3.7.5a-GA) with ESMTP id DVX86528 (AUTH peterg@ptree32.com.au); Wed, 16 Apr 2008 06:28:24 +1000 (EST) Message-ID: <48050FAC.6080407@freebsd.org> Date: Tue, 15 Apr 2008 13:27:24 -0700 From: Peter Grehan User-Agent: Thunderbird 2.0.0.0 (X11/20070525) MIME-Version: 1.0 To: Nathan Whitehorn References: <4804AE13.2060600@uchicago.edu> <4804C9E9.6010303@freebsd.org> <4804ECBA.5030905@uchicago.edu> In-Reply-To: <4804ECBA.5030905@uchicago.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-ppc@freebsd.org Subject: Re: G5 Bridge-mode MMU X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: grehan@freebsd.org List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Apr 2008 20:28:27 -0000 Hi Nathan, >> You really can't use the existing MMU code. The G5 was the driving >> factor to create the pmap indirection. > Yeah, the bridge mode MMU is just different enough to be annoying. I'm > using the existing code as a base, because (a) it's nice to have a > template, and (b) most of the PTE handling stuff can be reused with > s/struct pte/struct lpte and s/PTE/LPTE, and some changes to the hash > function and PTE_EXEC bits. Also, you may want to use 64-bit move instructions to atomically update PTEs in the hash table. > So you suggest saving OF's SDR1 and restoring it when we need to call > in? I guess this would solve part of the problem (debugging output while > initializing the MMU), but I'm sure sure I understand the real benefit > to this. I don't think the existing trick of putting OFW in it's own pmap will work. A full context switch, including SDR1, would give more confidence that OFW callbacks will work since it will be running in the address space it created. > So it should be generally true that all the local variables and > statically allocated things in pmap_bootstrap() should have virtual > addresses equal to their physical address? Yes, since at that point the kernel is running on a stack allocated in BSS. See tmpstk in locore.S. > Also, going to real mode seems like kind of a hack, but I think it may > be the best choice. I agree. Linux does it as well. >> - another 1:1 relic is the use of UMA_MD_SMALL_ALLOC. I talked with >> Alan Cox a long time back about being able to dynamically determine >> whether this could be used, though that is a fair amount of work. I >> would like to see a single kernel for G3/4/5, but that may be asking >> too much up front, especially given my lack of progress in achieving >> this goal :) > Well, once we have the page table set up, we can add a 1:1 mapping in > certain places -- e.g. low memory -- by adding in a whole bunch of 4 KB > pages. You have to be careful. A big advantage of the BAT mechanism is that a page's mod/ref bits aren't touched. If you have multiple mappings, you have to take care that you don't accidentally cause a page to be R/M'd when it shouldn't. Page-zeroing is an example: if you had 1:1 mappings, the page's R/M bits would have to be cleared after the zeroing. Or, make the pmap code aware of this. later, Peter. From owner-freebsd-ppc@FreeBSD.ORG Tue Apr 15 23:47:21 2008 Return-Path: Delivered-To: freebsd-ppc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6CE50106564A for ; Tue, 15 Apr 2008 23:47:21 +0000 (UTC) (envelope-from grehan@freebsd.org) Received: from alto.onthenet.com.au (alto.OntheNet.com.au [203.13.68.12]) by mx1.freebsd.org (Postfix) with ESMTP id 290068FC13 for ; Tue, 15 Apr 2008 23:47:21 +0000 (UTC) (envelope-from grehan@freebsd.org) Received: from dommail.onthenet.com.au (dommail.OntheNet.com.au [203.13.70.57]) by alto.onthenet.com.au (Postfix) with ESMTP id 7667611620; Wed, 16 Apr 2008 09:47:19 +1000 (EST) Received: from excfreebsd.hq.netapp.com (nat-198-95-226-228.netapp.com [198.95.226.228]) by dommail.onthenet.com.au (MOS 3.7.5a-GA) with ESMTP id DVY37126 (AUTH peterg@ptree32.com.au); Wed, 16 Apr 2008 09:47:15 +1000 (EST) Message-ID: <48053E46.4090700@freebsd.org> Date: Tue, 15 Apr 2008 16:46:14 -0700 From: Peter Grehan User-Agent: Thunderbird 2.0.0.0 (X11/20070525) MIME-Version: 1.0 To: Marcel Moolenaar References: <4804AE13.2060600@uchicago.edu> <4804C9E9.6010303@freebsd.org> <5CC81F06-7B59-4163-9AB8-2ACE4235A5AA@mac.com> <4804DD02.10304@freebsd.org> <058EEFE3-09D7-447A-93AB-3E90EC59ECDC@mac.com> In-Reply-To: <058EEFE3-09D7-447A-93AB-3E90EC59ECDC@mac.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-ppc@freebsd.org Subject: Re: kernel stacks [eas: Re: G5 Bridge-mode MMU] X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: grehan@freebsd.org List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Apr 2008 23:47:21 -0000 Hi Marcel, > the not mapping means that the CPU couldn't find the > translation in its TLB nor in the hash table. The exception code treats > this as a kernel stack overflow. Are you sure it isn't a genuine stack overflow ? You may be able to tell by bumping the size of tmpstk on a non-kstack0 boot and see how far up it's been used. The stack mappings are put into the hash table, and a panic will be issues if it can't be placed into the primary or secondary buckets. >> Stack *overflow* exception handling may be busted, but that is a >> challenging problem to get right. > > The logic currently assumes that there's never a DSI trap for the kernel > stack. This simply is an invalid assumption. As above, it is, since wired mappings are never kicked out of their hash bucket. >>> Also, with process address space limited to 2G >> >> Where's that limitation ? If so, that's a bug: it should be 4G. > > vmparam.h: #define VM_MAXUSER_ADDRESS 0x7ffff000 Ah yes, that's an easy one to fix :) later, Peter. From owner-freebsd-ppc@FreeBSD.ORG Wed Apr 16 00:42:43 2008 Return-Path: Delivered-To: freebsd-ppc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7BDC7106566B; Wed, 16 Apr 2008 00:42:43 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from smtpoutm.mac.com (smtpoutm.mac.com [17.148.16.71]) by mx1.freebsd.org (Postfix) with ESMTP id 2CDE68FC13; Wed, 16 Apr 2008 00:42:43 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from mac.com (asmtp002-s [10.150.69.65]) by smtpoutm.mac.com (Xserve/smtpout008/MantshX 4.0) with ESMTP id m3G0ggs7015909; Tue, 15 Apr 2008 17:42:42 -0700 (PDT) Received: from [192.168.1.100] (209-128-86-226.bayarea.net [209.128.86.226]) (authenticated bits=0) by mac.com (Xserve/asmtp002/MantshX 4.0) with ESMTP id m3G0geBM011122 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 15 Apr 2008 17:42:41 -0700 (PDT) Message-Id: From: Marcel Moolenaar To: grehan@freebsd.org In-Reply-To: <48053E46.4090700@freebsd.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v919.2) Date: Tue, 15 Apr 2008 17:42:40 -0700 References: <4804AE13.2060600@uchicago.edu> <4804C9E9.6010303@freebsd.org> <5CC81F06-7B59-4163-9AB8-2ACE4235A5AA@mac.com> <4804DD02.10304@freebsd.org> <058EEFE3-09D7-447A-93AB-3E90EC59ECDC@mac.com> <48053E46.4090700@freebsd.org> X-Mailer: Apple Mail (2.919.2) Cc: freebsd-ppc@freebsd.org Subject: Re: kernel stacks [eas: Re: G5 Bridge-mode MMU] X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Apr 2008 00:42:43 -0000 On Apr 15, 2008, at 4:46 PM, Peter Grehan wrote: > Hi Marcel, > >> the not mapping means that the CPU couldn't find the >> translation in its TLB nor in the hash table. The exception code >> treats >> this as a kernel stack overflow. > > Are you sure it isn't a genuine stack overflow ? Positive. The panic happens after 4KB of stack has been used. > You may be able to tell by bumping the size of tmpstk on a non- > kstack0 boot and see how far up it's been used. The backtrace also shows that. From inner-most to out-most function in the backtrace the stack pointers are roughly 4KB apart. > The stack mappings are put into the hash table, and a panic will be > issues if it can't be placed into the primary or secondary buckets. Hmm, It looks like you're right. Odd... Is it possible that the hash computation we use is not one used by the CPU so that we end up adding PTE where the CPU isn't looking? I'll have to dig deeper, I guess... -- Marcel Moolenaar xcllnt@mac.com From owner-freebsd-ppc@FreeBSD.ORG Wed Apr 16 00:53:56 2008 Return-Path: Delivered-To: freebsd-ppc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 446CE106566C for ; Wed, 16 Apr 2008 00:53:56 +0000 (UTC) (envelope-from grehan@freebsd.org) Received: from alto.onthenet.com.au (alto.OntheNet.com.au [203.13.68.12]) by mx1.freebsd.org (Postfix) with ESMTP id F372B8FC13 for ; Wed, 16 Apr 2008 00:53:55 +0000 (UTC) (envelope-from grehan@freebsd.org) Received: from dommail.onthenet.com.au (dommail.OntheNet.com.au [203.13.70.57]) by alto.onthenet.com.au (Postfix) with ESMTP id 1894D12756; Wed, 16 Apr 2008 10:53:54 +1000 (EST) Received: from excfreebsd.hq.netapp.com (nat-198-95-226-228.netapp.com [198.95.226.228]) by dommail.onthenet.com.au (MOS 3.7.5a-GA) with ESMTP id DVY53732 (AUTH peterg@ptree32.com.au); Wed, 16 Apr 2008 10:53:52 +1000 (EST) Message-ID: <48054DE6.10508@freebsd.org> Date: Tue, 15 Apr 2008 17:52:54 -0700 From: Peter Grehan User-Agent: Thunderbird 2.0.0.0 (X11/20070525) MIME-Version: 1.0 To: Marcel Moolenaar References: <4804AE13.2060600@uchicago.edu> <4804C9E9.6010303@freebsd.org> <5CC81F06-7B59-4163-9AB8-2ACE4235A5AA@mac.com> <4804DD02.10304@freebsd.org> <058EEFE3-09D7-447A-93AB-3E90EC59ECDC@mac.com> <48053E46.4090700@freebsd.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-ppc@freebsd.org Subject: Re: kernel stacks [eas: Re: G5 Bridge-mode MMU] X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: grehan@freebsd.org List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Apr 2008 00:53:56 -0000 Hi Marcel, >> Are you sure it isn't a genuine stack overflow ? > > Positive. The panic happens after 4KB of stack has been used. > >> You may be able to tell by bumping the size of tmpstk on a non-kstack0 >> boot and see how far up it's been used. > > The backtrace also shows that. From inner-most to out-most function in > the backtrace the stack pointers are roughly 4KB apart. Can you send the code snippet that you're using to set up the stack ? I can desk-check that, and then use it for my testing so we have the exact same setup. > Hmm, It looks like you're right. Odd... > > Is it possible that the hash computation we use is not one > used by the CPU so that we end up adding PTE where the CPU > isn't looking? No. If the primary hash didn't work, the system wouldn't work at all. For a long time there was a bug in the calculation of the secondary hash, but that has been fixed for a while now. Overflow of the secondary hash isn't handled at the moment, but since no-one has hit the panic, it isn't really a problem (yet). later, Peter. From owner-freebsd-ppc@FreeBSD.ORG Wed Apr 16 05:54:56 2008 Return-Path: Delivered-To: freebsd-ppc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4940B106566C; Wed, 16 Apr 2008 05:54:56 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from smtpoutm.mac.com (smtpoutm.mac.com [17.148.16.78]) by mx1.freebsd.org (Postfix) with ESMTP id 294A68FC1A; Wed, 16 Apr 2008 05:54:55 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from mac.com (asmtp002-s [10.150.69.65]) by smtpoutm.mac.com (Xserve/smtpout015/MantshX 4.0) with ESMTP id m3G5st0H007611; Tue, 15 Apr 2008 22:54:55 -0700 (PDT) Received: from [192.168.1.100] (209-128-86-226.bayarea.net [209.128.86.226]) (authenticated bits=0) by mac.com (Xserve/asmtp002/MantshX 4.0) with ESMTP id m3G5sosn028894 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 15 Apr 2008 22:54:52 -0700 (PDT) Message-Id: <9F6F2C83-79F1-4463-B9FF-4BBEB55B95B2@mac.com> From: Marcel Moolenaar To: grehan@freebsd.org In-Reply-To: <48054DE6.10508@freebsd.org> Content-Type: multipart/mixed; boundary=Apple-Mail-1-237339805 Mime-Version: 1.0 (Apple Message framework v919.2) Date: Tue, 15 Apr 2008 22:54:50 -0700 References: <4804AE13.2060600@uchicago.edu> <4804C9E9.6010303@freebsd.org> <5CC81F06-7B59-4163-9AB8-2ACE4235A5AA@mac.com> <4804DD02.10304@freebsd.org> <058EEFE3-09D7-447A-93AB-3E90EC59ECDC@mac.com> <48053E46.4090700@freebsd.org> <48054DE6.10508@freebsd.org> X-Mailer: Apple Mail (2.919.2) Cc: freebsd-ppc@freebsd.org Subject: Re: kernel stacks [eas: Re: G5 Bridge-mode MMU] X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Apr 2008 05:54:56 -0000 --Apple-Mail-1-237339805 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit On Apr 15, 2008, at 5:52 PM, Peter Grehan wrote: > Hi Marcel, > >>> Are you sure it isn't a genuine stack overflow ? >> Positive. The panic happens after 4KB of stack has been used. >>> You may be able to tell by bumping the size of tmpstk on a non- >>> kstack0 boot and see how far up it's been used. >> The backtrace also shows that. From inner-most to out-most function >> in >> the backtrace the stack pointers are roughly 4KB apart. > > Can you send the code snippet that you're using to set up the > stack ? I can desk-check that, and then use it for my testing so we > have the exact same setup. Diff attached. This is the problem I'm running into: Kernel entry at 0x100100 ... GDB: debug ports: uartGDB: current port: uart KDB: debugger backends: ddb gdb KDB: current backend: ddb Copyright (c) 1992-2008 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 8.0-CURRENT #8: Tue Apr 15 22:44:23 PDT 2008 marcel@xserve.xcllnt.net:/nfs/freebsd/8.x/src/sys/powerpc/compile/ XSERVE WARNING: WITNESS option enabled, expect reduced performance. cpu0: Motorola PowerPC 7455 revision 2.1, 1000.00 MHz cpu0: HID0 8450c0bc real memory = 527314944 (502 MB) avail memory = 510078976 (486 MB) nexus0: unin0: on nexus0 unin0: Version 36 pcib0: on nexus0 pci0: on pcib0 bge0: mem 0xa0000000-0xa000ffff irq 48 at device 16.0 on pci0 miibus0: on bge0 brgphy0: PHY 1 on miibus0 brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto bge0: Ethernet address: 00:03:93:c0:54:18 bge0: [ITHREAD] pcib1: on nexus0 pci1: on pcib1 pcib2: at device 13.0 on pci1 pci2: on pcib2 macio0: mem 0x80000000-0x8007ffff at device 7.0 on pci2 openpic0: mem 0x40000-0x7ffff on macio0 scc0: mem 0x13000-0x13fff,0x8400-0x84ff, 0x8500-0x85ff,0x8600-0x86ff,0x8700-0x87ff irq 22,23 on macio0 scc0: [FILTER] scc0: [FILTER] uart0: on scc0 uart0: [FILTER] uart0: console (57600,n,8,1) uart1: on scc0 uart1: [FILTER] ata0 mem 0x1f000-0x1ffff,0x8a00-0x8aff irq 19 on macio0 ata0: [ITHREAD] ohci0: mem 0x80081000-0x80081fff irq 27 at device 8.0 on pci2 ohci0: [GIANT-LOCKED] ohci0: [ITHREAD] usb0: OHCI version 1.0 usb0: on ohci0 usb0: USB revision 1.0 [thread pid 0 tid 100000 ] Stopped at 0x3e9cc0: stwux r0, r1, r9, db> bt Tracing pid 0 tid 100000 td 0x4cb340 0xd00040f0: at usbd_transfer+0xb0 0xd0004110: at usbd_sync_transfer+0x20 0xd0004120: at usbd_do_request_flags_pipe+0xa4 0xd0004170: at usbd_do_request_flags+0x40 0xd0004190: at usbd_get_string_desc+0x78 0xd00041c0: at usbd_get_string+0x94 0xd00042f0: at usbd_devinfo_vp+0x64 0xd0004310: at usbd_devinfo+0x48 0xd0004440: at usbd_new_device+0x5ac 0xd00048b0: at usb_attach+0x130 0xd0004a60: at device_attach+0x338 0xd0004a90: at device_probe_and_attach+0x134 0xd0004ab0: at ohci_pci_attach+0x6a8 0xd0004af0: at device_attach+0x338 0xd0004b20: at device_probe_and_attach+0x134 0xd0004b40: at bus_generic_attach+0x28 0xd0004b50: at pci_attach+0x118 0xd0004b80: at device_attach+0x338 0xd0004bb0: at device_probe_and_attach+0x134 0xd0004bd0: at bus_generic_attach+0x28 0xd0004be0: at ofw_pcib_pci_attach+0x78 0xd0004c10: at device_attach+0x338 0xd0004c40: at device_probe_and_attach+0x134 0xd0004c60: at bus_generic_attach+0x28 0xd0004c70: at pci_attach+0x118 0xd0004ca0: at device_attach+0x338 0xd0004cd0: at device_probe_and_attach+0x134 0xd0004cf0: at bus_generic_attach+0x28 0xd0004d00: at uninorth_attach+0x3e8 0xd0004d70: at device_attach+0x338 0xd0004da0: at device_probe_and_attach+0x134 0xd0004dc0: at bus_generic_attach+0x28 0xd0004dd0: at device_attach+0x338 0xd0004e00: at device_probe_and_attach+0x134 0xd0004e20: at root_bus_configure+0x30 0xd0004e30: at configure+0x14 0xd0004e40: at mi_startup+0x11c 0xd0004e70: at __start+0x98 db> show reg r0 0xd00040f0 r1 0xd00040b0 r2 0 r3 0xca76c0 r4 0 r5 0xd00041c8 r6 0x2 r7 0x1b998c usbd_start_transfer r8 0 r9 0xfffffee0 r10 0x200 dsisize+0x15c r11 0xd00040f0 r12 0x8c0 dsisize+0x81c r13 0 r14 0 r15 0 r16 0xcadd80 r17 0x100 dsisize+0x5c r18 0 r19 0xcae100 r20 0 r21 0xca7594 r22 0xcae080 r23 0x5 vectrapsize+0x1 r24 0xcade00 r25 0xd00041a0 r26 0x4 vectrapsize r27 0x1b998c usbd_start_transfer r28 0xc25600 r29 0xd00040b0 r30 0xc25600 r31 0xd00040b0 srr0 0x3e9cc0 bus_dmamap_load+0x4c srr1 0x3032 dsisize+0x2f8e lr 0x1ba190 usbd_transfer+0xb4 ctr 0 cr 0x24000082 xer 0 dar 0xd0003f90 dsisr 0 0x3e9cc0: stwux r0, r1, r9, db> As the backtrace shows, about 4K has been used, which means we're running into the second page. The reason we're hitting the debugger without a panic is because we're tripping over the stack overflow logic. In other words: we have a DSI trap. -- Marcel Moolenaar xcllnt@mac.com --Apple-Mail-1-237339805 Content-Disposition: attachment; filename=ppc.diff Content-Type: application/octet-stream; x-unix-mode=0644; name="ppc.diff" Content-Transfer-Encoding: 7bit Index: locore.S =================================================================== RCS file: /home/ncvs/src/sys/powerpc/aim/locore.S,v retrieving revision 1.25 diff -u -r1.25 locore.S --- locore.S 7 Mar 2008 22:27:05 -0000 1.25 +++ locore.S 16 Apr 2008 01:08:25 -0000 @@ -182,6 +182,7 @@ mr 7,21 bl powerpc_init + mr %r1, %r3 bl mi_startup b OF_exit Index: machdep.c =================================================================== RCS file: /home/ncvs/src/sys/powerpc/aim/machdep.c,v retrieving revision 1.111 diff -u -r1.111 machdep.c --- machdep.c 16 Mar 2008 10:58:08 -0000 1.111 +++ machdep.c 16 Apr 2008 05:40:29 -0000 @@ -132,9 +132,6 @@ static struct pcpu pcpu0; static struct trapframe frame0; -vm_offset_t kstack0; -vm_offset_t kstack0_phys; - char machine[] = "powerpc"; SYSCTL_STRING(_hw, HW_MACHINE, machine, CTLFLAG_RD, machine, 0, ""); @@ -145,7 +142,7 @@ static void cpu_startup(void *); SYSINIT(cpu, SI_SUB_CPU, SI_ORDER_FIRST, cpu_startup, NULL); -void powerpc_init(u_int, u_int, u_int, void *); +u_int powerpc_init(u_int, u_int, u_int, void *); int save_ofw_mapping(void); int restore_ofw_mapping(void); @@ -248,11 +245,11 @@ extern void *dblow, *dbsize; extern void *vectrap, *vectrapsize; -void +u_int powerpc_init(u_int startkernel, u_int endkernel, u_int basekernel, void *mdp) { struct pcpu *pc; - vm_offset_t end, off; + vm_offset_t end; void *kmdp; char *env; @@ -295,7 +292,6 @@ pc = &pcpu0; pcpu_init(pc, 0, sizeof(struct pcpu)); pc->pc_curthread = &thread0; - pc->pc_curpcb = thread0.td_pcb; pc->pc_cpuid = 0; __asm __volatile("mtsprg 0, %0" :: "r"(pc)); @@ -379,15 +375,12 @@ /* * Finish setting up thread0. */ - thread0.td_kstack = kstack0; thread0.td_pcb = (struct pcb *) - (thread0.td_kstack + KSTACK_PAGES * PAGE_SIZE) - 1; + ((thread0.td_kstack + thread0.td_kstack_pages * PAGE_SIZE - + sizeof(struct pcb)) & ~0xfU); + pc->pc_curpcb = thread0.td_pcb; - /* - * Map and initialise the message buffer. - */ - for (off = 0; off < round_page(MSGBUF_SIZE); off += PAGE_SIZE) - pmap_kenter((vm_offset_t)msgbufp + off, msgbuf_phys + off); + /* Initialise the message buffer. */ msgbufinit(msgbufp, MSGBUF_SIZE); #ifdef KDB @@ -395,6 +388,8 @@ kdb_enter(KDB_WHY_BOOTFLAGS, "Boot flags requested debugger"); #endif + + return (((uintptr_t)thread0.td_pcb - 16) & ~15); } void Index: mmu_oea.c =================================================================== RCS file: /home/ncvs/src/sys/powerpc/aim/mmu_oea.c,v retrieving revision 1.117 diff -u -r1.117 mmu_oea.c --- mmu_oea.c 14 Dec 2007 22:39:34 -0000 1.117 +++ mmu_oea.c 16 Apr 2008 05:37:46 -0000 @@ -785,11 +785,6 @@ MTX_RECURSE); /* - * Allocate the message buffer. - */ - msgbuf_phys = moea_bootstrap_alloc(MSGBUF_SIZE, 0); - - /* * Initialise the unmanaged pvo pool. */ moea_bpvo_pool = (struct pvo_entry *)moea_bootstrap_alloc( @@ -872,48 +867,56 @@ kernel_pmap->pm_active = ~0; /* - * Allocate a kernel stack with a guard page for thread0 and map it - * into the kernel page map. + * Initialize hardware. */ - pa = moea_bootstrap_alloc(KSTACK_PAGES * PAGE_SIZE, 0); - kstack0_phys = pa; - kstack0 = virtual_avail + (KSTACK_GUARD_PAGES * PAGE_SIZE); - CTR2(KTR_PMAP, "moea_bootstrap: kstack0 at %#x (%#x)", kstack0_phys, - kstack0); - virtual_avail += (KSTACK_PAGES + KSTACK_GUARD_PAGES) * PAGE_SIZE; - for (i = 0; i < KSTACK_PAGES; i++) { - pa = kstack0_phys + i * PAGE_SIZE; - va = kstack0 + i * PAGE_SIZE; - moea_kenter(mmup, va, pa); - TLBIE(va); + for (i = 0; i < 16; i++) { + mtsrin(i << ADDR_SR_SHFT, EMPTY_SEGMENT); } + __asm __volatile ("mtsr %0,%1" + :: "n"(KERNEL_SR), "r"(KERNEL_SEGMENT)); + __asm __volatile ("mtsr %0,%1" + :: "n"(KERNEL2_SR), "r"(KERNEL2_SEGMENT)); + __asm __volatile ("sync; mtsdr1 %0; isync" + :: "r"((u_int)moea_pteg_table | (moea_pteg_mask >> 10))); + tlbia(); /* - * Calculate the last available physical address. + * Allocate a kernel stack with a guard page for thread0 and map it + * into the kernel page map. */ - for (i = 0; phys_avail[i + 2] != 0; i += 2) - ; - Maxmem = powerpc_btop(phys_avail[i + 1]); + pa = moea_bootstrap_alloc(KSTACK_PAGES * PAGE_SIZE, PAGE_SIZE); + va = virtual_avail + KSTACK_GUARD_PAGES * PAGE_SIZE; + virtual_avail = va + KSTACK_PAGES * PAGE_SIZE; + CTR2(KTR_PMAP, "moea_bootstrap: kstack0 at %#x (%#x)", pa, va); + thread0.td_kstack = va; + thread0.td_kstack_pages = KSTACK_PAGES; + + for (i = 0; i < KSTACK_PAGES; i++) { + moea_kenter(mmup, va, pa);; + pa += PAGE_SIZE; + va += PAGE_SIZE; + } /* * Allocate virtual address space for the message buffer. */ + pa = msgbuf_phys = moea_bootstrap_alloc(MSGBUF_SIZE, PAGE_SIZE); msgbufp = (struct msgbuf *)virtual_avail; + va = virtual_avail; virtual_avail += round_page(MSGBUF_SIZE); + while (va < virtual_avail) { + moea_kenter(mmup, va, pa);; + pa += PAGE_SIZE; + va += PAGE_SIZE; + } + /* - * Initialize hardware. + * Calculate the last available physical address. */ - for (i = 0; i < 16; i++) { - mtsrin(i << ADDR_SR_SHFT, EMPTY_SEGMENT); - } - __asm __volatile ("mtsr %0,%1" - :: "n"(KERNEL_SR), "r"(KERNEL_SEGMENT)); - __asm __volatile ("mtsr %0,%1" - :: "n"(KERNEL2_SR), "r"(KERNEL2_SEGMENT)); - __asm __volatile ("sync; mtsdr1 %0; isync" - :: "r"((u_int)moea_pteg_table | (moea_pteg_mask >> 10))); - tlbia(); + for (i = 0; phys_avail[i + 2] != 0; i += 2) + ; + Maxmem = powerpc_btop(phys_avail[i + 1]); pmap_bootstrapped++; } --Apple-Mail-1-237339805 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit --Apple-Mail-1-237339805-- From owner-freebsd-ppc@FreeBSD.ORG Wed Apr 16 14:09:33 2008 Return-Path: Delivered-To: powerpc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0AD441065673; Wed, 16 Apr 2008 14:09:33 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id D69598FC13; Wed, 16 Apr 2008 14:09:32 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.14.2/8.14.2) with ESMTP id m3GE9Wct013618; Wed, 16 Apr 2008 10:09:32 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.14.2/8.14.2) with ESMTP id m3GE9WD6028674; Wed, 16 Apr 2008 10:09:32 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id E69DF73039; Wed, 16 Apr 2008 10:09:31 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20080416140931.E69DF73039@freebsd-current.sentex.ca> Date: Wed, 16 Apr 2008 10:09:31 -0400 (EDT) X-Virus-Scanned: ClamAV 0.92.1/6526/Tue Apr 1 08:33:51 2008 clamav-milter version 0.92.1 on clamscanner2 X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on powerpc/powerpc X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Apr 2008 14:09:33 -0000 TB --- 2008-04-16 13:00:45 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2008-04-16 13:00:45 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2008-04-16 13:00:45 - cleaning the object tree TB --- 2008-04-16 13:01:11 - cvsupping the source tree TB --- 2008-04-16 13:01:11 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/powerpc/powerpc/supfile TB --- 2008-04-16 13:01:20 - building world (CFLAGS=-O -pipe) TB --- 2008-04-16 13:01:20 - cd /src TB --- 2008-04-16 13:01:20 - /usr/bin/make -B buildworld >>> World build started on Wed Apr 16 13:01:21 UTC 2008 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Wed Apr 16 14:04:21 UTC 2008 TB --- 2008-04-16 14:04:21 - generating LINT kernel config TB --- 2008-04-16 14:04:21 - cd /src/sys/powerpc/conf TB --- 2008-04-16 14:04:21 - /usr/bin/make -B LINT TB --- 2008-04-16 14:04:21 - building LINT kernel (COPTFLAGS=) TB --- 2008-04-16 14:04:21 - cd /src TB --- 2008-04-16 14:04:21 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Wed Apr 16 14:04:21 UTC 2008 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -ffreestanding -Werror /src/sys/kern/kern_kthread.c cc -c -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -ffreestanding -Werror /src/sys/kern/kern_ktr.c cc -c -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -ffreestanding -Werror /src/sys/kern/kern_ktrace.c cc -c -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -ffreestanding -Werror /src/sys/kern/kern_linker.c cc -c -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -ffreestanding -Werror /src/sys/kern/kern_lock.c cc -c -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -ffreestanding -Werror /src/sys/kern/kern_lockf.c /src/sys/kern/kern_lockf.c: In function 'lf_printlist': /src/sys/kern/kern_lockf.c:2392: error: 'struct inode' has no member named 'i_lockf' *** Error code 1 Stop in /obj/powerpc/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-04-16 14:09:31 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-04-16 14:09:31 - ERROR: failed to build lint kernel TB --- 2008-04-16 14:09:31 - tinderbox aborted TB --- 3039.46 user 365.00 system 4125.87 real http://tinderbox.des.no/tinderbox-head-HEAD-powerpc-powerpc.full From owner-freebsd-ppc@FreeBSD.ORG Wed Apr 16 21:27:40 2008 Return-Path: Delivered-To: freebsd-ppc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E52821065671; Wed, 16 Apr 2008 21:27:40 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from smtpoutm.mac.com (smtpoutm.mac.com [17.148.16.78]) by mx1.freebsd.org (Postfix) with ESMTP id CAE778FC0C; Wed, 16 Apr 2008 21:27:40 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from mac.com (asmtp005-s [10.150.69.68]) by smtpoutm.mac.com (Xserve/smtpout015/MantshX 4.0) with ESMTP id m3GLRe7O012298; Wed, 16 Apr 2008 14:27:40 -0700 (PDT) Received: from [192.168.1.100] (209-128-86-226.bayarea.net [209.128.86.226]) (authenticated bits=0) by mac.com (Xserve/asmtp005/MantshX 4.0) with ESMTP id m3GLRcAY026569 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 16 Apr 2008 14:27:38 -0700 (PDT) Message-Id: <8D15A3AC-BEF7-46DF-9166-C1D44BFD32EE@mac.com> From: Marcel Moolenaar To: Peter Grehan In-Reply-To: <9F6F2C83-79F1-4463-B9FF-4BBEB55B95B2@mac.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v919.2) Date: Wed, 16 Apr 2008 14:27:37 -0700 References: <4804AE13.2060600@uchicago.edu> <4804C9E9.6010303@freebsd.org> <5CC81F06-7B59-4163-9AB8-2ACE4235A5AA@mac.com> <4804DD02.10304@freebsd.org> <058EEFE3-09D7-447A-93AB-3E90EC59ECDC@mac.com> <48053E46.4090700@freebsd.org> <48054DE6.10508@freebsd.org> <9F6F2C83-79F1-4463-B9FF-4BBEB55B95B2@mac.com> X-Mailer: Apple Mail (2.919.2) Cc: freebsd-ppc@freebsd.org Subject: Re: kernel stacks [eas: Re: G5 Bridge-mode MMU] X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Apr 2008 21:27:41 -0000 Follow-up... On Apr 15, 2008, at 10:54 PM, Marcel Moolenaar wrote: > > On Apr 15, 2008, at 5:52 PM, Peter Grehan wrote: >> Hi Marcel, >> >>>> Are you sure it isn't a genuine stack overflow ? >>> Positive. The panic happens after 4KB of stack has been used. >>>> You may be able to tell by bumping the size of tmpstk on a non- >>>> kstack0 boot and see how far up it's been used. >>> The backtrace also shows that. From inner-most to out-most >>> function in >>> the backtrace the stack pointers are roughly 4KB apart. >> >> Can you send the code snippet that you're using to set up the >> stack ? I can desk-check that, and then use it for my testing so we >> have the exact same setup. *snip* >> usb0: USB revision 1.0 > [thread pid 0 tid 100000 ] > Stopped at 0x3e9cc0: stwux r0, r1, r9, > db> bt > Tracing pid 0 tid 100000 td 0x4cb340 > 0xd00040f0: at usbd_transfer+0xb0 *snip* Found the problem: moea_rkva_alloc(). The first 4 pages of KVA are reserved for page zeroing and other special purpose uses. This was not accounted for in the original moea_bootstrap() code when the kernel stack was allocated, so the kernel stack overlapped with the pages returned by moea_rkva_alloc(). This is easily fixed... -- Marcel Moolenaar xcllnt@mac.com From owner-freebsd-ppc@FreeBSD.ORG Wed Apr 16 22:24:52 2008 Return-Path: Delivered-To: freebsd-ppc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 93941106564A for ; Wed, 16 Apr 2008 22:24:52 +0000 (UTC) (envelope-from grehan@freebsd.org) Received: from alto.onthenet.com.au (alto.OntheNet.com.au [203.13.68.12]) by mx1.freebsd.org (Postfix) with ESMTP id 4D8108FC1C for ; Wed, 16 Apr 2008 22:24:52 +0000 (UTC) (envelope-from grehan@freebsd.org) Received: from dommail.onthenet.com.au (dommail.OntheNet.com.au [203.13.70.57]) by alto.onthenet.com.au (Postfix) with ESMTP id BC9141149A; Thu, 17 Apr 2008 08:24:49 +1000 (EST) Received: from peter-grehans-power-mac-g5.local (dsl-63-249-90-35.cruzio.com [63.249.90.35]) by dommail.onthenet.com.au (MOS 3.8.6-GA) with ESMTP id DWI10568 (AUTH peterg@ptree32.com.au); Thu, 17 Apr 2008 08:24:49 +1000 (EST) Message-ID: <48067CAB.5030002@freebsd.org> Date: Wed, 16 Apr 2008 15:24:43 -0700 From: Peter Grehan User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) MIME-Version: 1.0 To: Marcel Moolenaar References: <4804AE13.2060600@uchicago.edu> <4804C9E9.6010303@freebsd.org> <5CC81F06-7B59-4163-9AB8-2ACE4235A5AA@mac.com> <4804DD02.10304@freebsd.org> <058EEFE3-09D7-447A-93AB-3E90EC59ECDC@mac.com> <48053E46.4090700@freebsd.org> <48054DE6.10508@freebsd.org> <9F6F2C83-79F1-4463-B9FF-4BBEB55B95B2@mac.com> <8D15A3AC-BEF7-46DF-9166-C1D44BFD32EE@mac.com> In-Reply-To: <8D15A3AC-BEF7-46DF-9166-C1D44BFD32EE@mac.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-ppc@freebsd.org Subject: Re: kernel stacks [eas: Re: G5 Bridge-mode MMU] X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: grehan@freebsd.org List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Apr 2008 22:24:52 -0000 Hi Marcel, > Found the problem: moea_rkva_alloc(). > > The first 4 pages of KVA are reserved for page zeroing and other > special purpose uses. This was not accounted for in the original > moea_bootstrap() code when the kernel stack was allocated, so the > kernel stack overlapped with the pages returned by moea_rkva_alloc(). Good catch :) > This is easily fixed... The rkva_alloc routine can be removed. The original check for SEGMENT_LENGTH in the page_zero routines must have been a relic from the days when only BAT0 was used. It is safe to simply bzero the physical address and rely on the 1:1 BAT mappings for all of phys mem. later, Peter. From owner-freebsd-ppc@FreeBSD.ORG Fri Apr 18 13:25:48 2008 Return-Path: Delivered-To: powerpc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 942A6106566B; Fri, 18 Apr 2008 13:25:48 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id 63EE18FC12; Fri, 18 Apr 2008 13:25:48 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.14.2/8.14.2) with ESMTP id m3IDPluJ024605; Fri, 18 Apr 2008 09:25:47 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-stable.sentex.ca (freebsd-stable.sentex.ca [64.7.128.103]) by smtp2.sentex.ca (8.14.2/8.14.2) with ESMTP id m3IDPt4M052175; Fri, 18 Apr 2008 09:25:55 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-stable.sentex.ca (Postfix, from userid 666) id 7D6001B5078; Fri, 18 Apr 2008 09:25:47 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20080418132547.7D6001B5078@freebsd-stable.sentex.ca> Date: Fri, 18 Apr 2008 09:25:47 -0400 (EDT) X-Virus-Scanned: ClamAV 0.92.1/6526/Tue Apr 1 08:33:51 2008 clamav-milter version 0.92.1 on clamscanner3 X-Virus-Status: Clean Cc: Subject: [releng_7 tinderbox] failure on powerpc/powerpc X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Apr 2008 13:25:48 -0000 TB --- 2008-04-18 12:15:49 - tinderbox 2.3 running on freebsd-stable.sentex.ca TB --- 2008-04-18 12:15:49 - starting RELENG_7 tinderbox run for powerpc/powerpc TB --- 2008-04-18 12:15:49 - cleaning the object tree TB --- 2008-04-18 12:16:07 - cvsupping the source tree TB --- 2008-04-18 12:16:07 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/RELENG_7/powerpc/powerpc/supfile TB --- 2008-04-18 12:16:14 - building world (CFLAGS=-O2 -pipe) TB --- 2008-04-18 12:16:14 - cd /src TB --- 2008-04-18 12:16:14 - /usr/bin/make -B buildworld >>> World build started on Fri Apr 18 12:16:15 UTC 2008 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Fri Apr 18 13:22:15 UTC 2008 TB --- 2008-04-18 13:22:15 - generating LINT kernel config TB --- 2008-04-18 13:22:15 - cd /src/sys/powerpc/conf TB --- 2008-04-18 13:22:15 - /usr/bin/make -B LINT TB --- 2008-04-18 13:22:15 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2008-04-18 13:22:15 - cd /src TB --- 2008-04-18 13:22:15 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Fri Apr 18 13:22:15 UTC 2008 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -ffreestanding -Werror /src/sys/dev/cmx/cmx_pccard.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -ffreestanding -Werror /src/sys/dev/cnw/if_cnw.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -ffreestanding -Werror /src/sys/dev/cxgb/cxgb_main.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -ffreestanding -Werror /src/sys/dev/cxgb/cxgb_offload.c cc1: warnings being treated as errors /src/sys/dev/cxgb/cxgb_offload.c: In function 'do_bad_cpl': /src/sys/dev/cxgb/cxgb_offload.c:318: warning: implicit declaration of function 'kdb_backtrace' /src/sys/dev/cxgb/cxgb_offload.c:318: warning: nested extern declaration of 'kdb_backtrace' *** Error code 1 Stop in /obj/powerpc/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-04-18 13:25:47 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-04-18 13:25:47 - ERROR: failed to build lint kernel TB --- 2008-04-18 13:25:47 - tinderbox aborted TB --- 3481.16 user 356.90 system 4198.33 real http://tinderbox.des.no/tinderbox-releng_7-RELENG_7-powerpc-powerpc.full From owner-freebsd-ppc@FreeBSD.ORG Fri Apr 18 23:55:18 2008 Return-Path: Delivered-To: powerpc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 961941065705; Fri, 18 Apr 2008 23:55:18 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id 68C778FC20; Fri, 18 Apr 2008 23:55:18 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.14.2/8.14.2) with ESMTP id m3INtHwu099905; Fri, 18 Apr 2008 19:55:17 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-stable.sentex.ca (freebsd-stable.sentex.ca [64.7.128.103]) by smtp2.sentex.ca (8.14.2/8.14.2) with ESMTP id m3INtHaE087669; Fri, 18 Apr 2008 19:55:17 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-stable.sentex.ca (Postfix, from userid 666) id 489B01B5078; Fri, 18 Apr 2008 19:55:17 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20080418235517.489B01B5078@freebsd-stable.sentex.ca> Date: Fri, 18 Apr 2008 19:55:17 -0400 (EDT) X-Virus-Scanned: ClamAV 0.92.1/6526/Tue Apr 1 08:33:51 2008 clamav-milter version 0.92.1 on clamscanner3 X-Virus-Status: Clean Cc: Subject: [releng_7 tinderbox] failure on powerpc/powerpc X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Apr 2008 23:55:19 -0000 TB --- 2008-04-18 22:45:46 - tinderbox 2.3 running on freebsd-stable.sentex.ca TB --- 2008-04-18 22:45:46 - starting RELENG_7 tinderbox run for powerpc/powerpc TB --- 2008-04-18 22:45:46 - cleaning the object tree TB --- 2008-04-18 22:46:00 - cvsupping the source tree TB --- 2008-04-18 22:46:00 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/RELENG_7/powerpc/powerpc/supfile TB --- 2008-04-18 22:46:07 - building world (CFLAGS=-O2 -pipe) TB --- 2008-04-18 22:46:07 - cd /src TB --- 2008-04-18 22:46:07 - /usr/bin/make -B buildworld >>> World build started on Fri Apr 18 22:46:08 UTC 2008 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Fri Apr 18 23:51:46 UTC 2008 TB --- 2008-04-18 23:51:46 - generating LINT kernel config TB --- 2008-04-18 23:51:46 - cd /src/sys/powerpc/conf TB --- 2008-04-18 23:51:46 - /usr/bin/make -B LINT TB --- 2008-04-18 23:51:46 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2008-04-18 23:51:46 - cd /src TB --- 2008-04-18 23:51:46 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Fri Apr 18 23:51:46 UTC 2008 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -ffreestanding -Werror /src/sys/dev/cmx/cmx_pccard.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -ffreestanding -Werror /src/sys/dev/cnw/if_cnw.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -ffreestanding -Werror /src/sys/dev/cxgb/cxgb_main.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -ffreestanding -Werror /src/sys/dev/cxgb/cxgb_offload.c cc1: warnings being treated as errors /src/sys/dev/cxgb/cxgb_offload.c: In function 'do_bad_cpl': /src/sys/dev/cxgb/cxgb_offload.c:318: warning: implicit declaration of function 'kdb_backtrace' /src/sys/dev/cxgb/cxgb_offload.c:318: warning: nested extern declaration of 'kdb_backtrace' *** Error code 1 Stop in /obj/powerpc/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-04-18 23:55:17 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-04-18 23:55:17 - ERROR: failed to build lint kernel TB --- 2008-04-18 23:55:17 - tinderbox aborted TB --- 3484.13 user 351.03 system 4171.06 real http://tinderbox.des.no/tinderbox-releng_7-RELENG_7-powerpc-powerpc.full From owner-freebsd-ppc@FreeBSD.ORG Sat Apr 19 05:08:52 2008 Return-Path: Delivered-To: powerpc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EA250106566C; Sat, 19 Apr 2008 05:08:52 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id A3DFA8FC0A; Sat, 19 Apr 2008 05:08:52 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1c.sentex.ca [64.7.153.10]) by smarthost1.sentex.ca (8.14.2/8.14.2) with ESMTP id m3J58qJk015724; Sat, 19 Apr 2008 01:08:52 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.14.2/8.14.2) with ESMTP id m3J58pTM089592; Sat, 19 Apr 2008 01:08:51 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id B36D273039; Sat, 19 Apr 2008 01:08:51 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20080419050851.B36D273039@freebsd-current.sentex.ca> Date: Sat, 19 Apr 2008 01:08:51 -0400 (EDT) X-Virus-Scanned: ClamAV version 0.92, clamav-milter version 0.92 on clamscanner2 X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on powerpc/powerpc X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Apr 2008 05:08:53 -0000 TB --- 2008-04-19 04:00:37 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2008-04-19 04:00:37 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2008-04-19 04:00:37 - cleaning the object tree TB --- 2008-04-19 04:01:05 - cvsupping the source tree TB --- 2008-04-19 04:01:05 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/powerpc/powerpc/supfile TB --- 2008-04-19 04:01:11 - building world (CFLAGS=-O -pipe) TB --- 2008-04-19 04:01:11 - cd /src TB --- 2008-04-19 04:01:11 - /usr/bin/make -B buildworld >>> World build started on Sat Apr 19 04:01:13 UTC 2008 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Sat Apr 19 05:05:25 UTC 2008 TB --- 2008-04-19 05:05:25 - generating LINT kernel config TB --- 2008-04-19 05:05:25 - cd /src/sys/powerpc/conf TB --- 2008-04-19 05:05:25 - /usr/bin/make -B LINT TB --- 2008-04-19 05:05:25 - building LINT kernel (COPTFLAGS=) TB --- 2008-04-19 05:05:25 - cd /src TB --- 2008-04-19 05:05:25 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat Apr 19 05:05:25 UTC 2008 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -ffreestanding -Werror /src/sys/dev/cmx/cmx_pccard.c cc -c -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -ffreestanding -Werror /src/sys/dev/cnw/if_cnw.c cc -c -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -ffreestanding -Werror /src/sys/dev/cxgb/cxgb_main.c cc -c -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -ffreestanding -Werror /src/sys/dev/cxgb/cxgb_offload.c cc1: warnings being treated as errors /src/sys/dev/cxgb/cxgb_offload.c: In function 'do_bad_cpl': /src/sys/dev/cxgb/cxgb_offload.c:318: warning: implicit declaration of function 'kdb_backtrace' /src/sys/dev/cxgb/cxgb_offload.c:318: warning: nested extern declaration of 'kdb_backtrace' *** Error code 1 Stop in /obj/powerpc/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-04-19 05:08:51 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-04-19 05:08:51 - ERROR: failed to build lint kernel TB --- 2008-04-19 05:08:51 - tinderbox aborted TB --- 2961.99 user 353.84 system 4093.89 real http://tinderbox.des.no/tinderbox-head-HEAD-powerpc-powerpc.full