From owner-freebsd-sparc64@FreeBSD.ORG Mon Oct 21 11:06:55 2013 Return-Path: Delivered-To: freebsd-sparc64@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 0F76BA6A for ; Mon, 21 Oct 2013 11:06:55 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id F0A1B2E29 for ; Mon, 21 Oct 2013 11:06:54 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r9LB6skU018780 for ; Mon, 21 Oct 2013 11:06:54 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r9LB6s4U018778 for freebsd-sparc64@FreeBSD.org; Mon, 21 Oct 2013 11:06:54 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 21 Oct 2013 11:06:54 GMT Message-Id: <201310211106.r9LB6s4U018778@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-sparc64@FreeBSD.org Subject: Current problem reports assigned to freebsd-sparc64@FreeBSD.org X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Oct 2013 11:06:55 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o sparc/170663 sparc64 panics with VIA 6421 SATA150 controller on Blade 1500 o sparc/169669 sparc64 Something seems broken in sparc64 TLS or lang/lua o sparc/164227 sparc64 [boot] Can't boot 9.0-RELEASE/sparc64 on Blade 1500 s sparc/164226 sparc64 [cd] Data corruption on 9.0-RELEASE when reading from o sparc/162513 sparc64 mpt(4), mptutil(8) reports variable, erroneous drive i o sparc/141918 sparc64 [ehci] ehci_interrupt: unrecoverable error, controller s sparc/139134 sparc64 kernel output corruption s sparc/107087 sparc64 [hang] system is hung during boot from CD o sparc/105048 sparc64 [trm] trm(4) panics on sparc64 o sparc/104428 sparc64 [nullfs] nullfs panics on E4500 (but not E420) o sparc/71729 sparc64 printf in kernel thread causes panic on SPARC 11 problems total. From owner-freebsd-sparc64@FreeBSD.ORG Wed Oct 23 20:36:02 2013 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 5F630749 for ; Wed, 23 Oct 2013 20:36:02 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from mail.icecube.wisc.edu (trout.icecube.wisc.edu [128.104.255.119]) by mx1.freebsd.org (Postfix) with ESMTP id 345E42EC0 for ; Wed, 23 Oct 2013 20:36:01 +0000 (UTC) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.icecube.wisc.edu (Postfix) with ESMTP id 2566A5838A for ; Wed, 23 Oct 2013 15:35:55 -0500 (CDT) X-Virus-Scanned: amavisd-new at icecube.wisc.edu Received: from mail.icecube.wisc.edu ([127.0.0.1]) by localhost (trout.icecube.wisc.edu [127.0.0.1]) (amavisd-new, port 10030) with ESMTP id VWH3H79Y6rvJ for ; Wed, 23 Oct 2013 15:35:55 -0500 (CDT) Received: from terminus.icecube.wisc.edu (terminus.icecube.wisc.edu [172.16.223.97]) by mail.icecube.wisc.edu (Postfix) with ESMTP id 501B558388 for ; Wed, 23 Oct 2013 15:35:54 -0500 (CDT) Message-ID: <5268332A.6080107@freebsd.org> Date: Wed, 23 Oct 2013 15:35:54 -0500 From: Nathan Whitehorn User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: freebsd-sparc64@freebsd.org Subject: Nexus improvements Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Oct 2013 20:36:02 -0000 I've been trying for the last few days to clean up some of our OF/FDT code, in particular related to reducing code duplication. There is a 12-year-old comment in sparc64/sparc64/nexus.c that "this code should get into dev/ofw to some extent". Most of the code has been moved now and the PowerPC nexus device has been replaced by the pieces of the sparc64 one that now do live in dev/ofw. The following (almost entirely negative) patch moves sparc64 to use it as well. Since it is just a copy of the sparc64 code, this should involve no functional changes, and I will commit it in a few days unless someone raises an objection. The patch is only compile tested for the time being, so hardware tests would be appreciated. Patch at: http://people.freebsd.org/~nwhitehorn/sparc64-nexus-unify.diff -Nathan From owner-freebsd-sparc64@FreeBSD.ORG Thu Oct 24 16:15:14 2013 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 7BC7D205; Thu, 24 Oct 2013 16:15:14 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (alchemy.franken.de [194.94.249.214]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id EF8DE28E6; Thu, 24 Oct 2013 16:15:13 +0000 (UTC) Received: from alchemy.franken.de (localhost [127.0.0.1]) by alchemy.franken.de (8.14.7/8.14.7/ALCHEMY.FRANKEN.DE) with ESMTP id r9OFpU7h014429; Thu, 24 Oct 2013 17:51:30 +0200 (CEST) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.14.7/8.14.7/Submit) id r9OFpUHt014428; Thu, 24 Oct 2013 17:51:30 +0200 (CEST) (envelope-from marius) Date: Thu, 24 Oct 2013 17:51:30 +0200 From: Marius Strobl To: Nathan Whitehorn Subject: Re: Nexus improvements Message-ID: <20131024155130.GA14293@alchemy.franken.de> References: <5268332A.6080107@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5268332A.6080107@freebsd.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-sparc64@freebsd.org X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Oct 2013 16:15:14 -0000 On Wed, Oct 23, 2013 at 03:35:54PM -0500, Nathan Whitehorn wrote: > I've been trying for the last few days to clean up some of our OF/FDT > code, in particular related to reducing code duplication. There is a > 12-year-old comment in sparc64/sparc64/nexus.c that "this code should > get into dev/ofw to some extent". Most of the code has been moved now > and the PowerPC nexus device has been replaced by the pieces of the > sparc64 one that now do live in dev/ofw. The following (almost entirely > negative) patch moves sparc64 to use it as well. Since it is just a copy > of the sparc64 code, this should involve no functional changes, and I > will commit it in a few days unless someone raises an objection. The > patch is only compile tested for the time being, so hardware tests would > be appreciated. > > Patch at: http://people.freebsd.org/~nwhitehorn/sparc64-nexus-unify.diff Well, as is this patch breaks resource allocation in a strange way: nexus0: pcib0: mem 0x4000f600000-0x4000f6effff,0x4000f410000-0x4000f473fff irq 1983,1982 on nexus0 panic: fire_attach: could not allocate register bank 0 I didn't try to figure out what's going on as I'm still not very fond of sharing that code across platforms. The comment you are referring to is - as you are also pointing out - rather old and applied to a sparc64 nexus(4) that was quite different than the current version and f. e. didn't do resource management of its children based on OFW information. In particular, "true" MI code shouldn't have #ifdefs with very MD code like the one your patch would introduce. Similarly, the device exclude lists shouldn't be shared across all platforms as one might want to exclude a specific device whilst another does not. Having the whole lists in unconditionally also just wastes memory on embedded machinery. Also, switching sparc64 to use the current dev/ofw/ofw_nexus.c would introduce some subtle differences compared to how things currently work with the MD nexus(4). At a quick glance that would be: o the interrupts RMAN range gets extended from IV_MAX - 1 to ~0, which means no longer sanity checking for out-of-range interrupts, o devices without at least memory resources get added as children, while previously they were skipped. Marius From owner-freebsd-sparc64@FreeBSD.ORG Thu Oct 24 16:49:43 2013 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id B8811C23 for ; Thu, 24 Oct 2013 16:49:43 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from smtpauth3.wiscmail.wisc.edu (wmauth3.doit.wisc.edu [144.92.197.226]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 8A15E2ADA for ; Thu, 24 Oct 2013 16:49:43 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII; format=flowed Received: from avs-daemon.smtpauth3.wiscmail.wisc.edu by smtpauth3.wiscmail.wisc.edu (Oracle Communications Messaging Server 7u4-27.01(7.0.4.27.0) 64bit (built Aug 30 2012)) id <0MV600800MOSP900@smtpauth3.wiscmail.wisc.edu> for freebsd-sparc64@freebsd.org; Thu, 24 Oct 2013 11:49:36 -0500 (CDT) X-Spam-PmxInfo: Server=avs-3, Version=6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2013.10.24.163915, SenderIP=0.0.0.0 X-Spam-Report: AuthenticatedSender=yes, SenderIP=0.0.0.0 Received: from comporellon.tachypleus.net (adsl-76-208-69-44.dsl.mdsnwi.sbcglobal.net [76.208.69.44]) by smtpauth3.wiscmail.wisc.edu (Oracle Communications Messaging Server 7u4-27.01(7.0.4.27.0) 64bit (built Aug 30 2012)) with ESMTPSA id <0MV600I1GMQLQB20@smtpauth3.wiscmail.wisc.edu>; Thu, 24 Oct 2013 11:49:34 -0500 (CDT) Message-id: <52694F9D.6000705@freebsd.org> Date: Thu, 24 Oct 2013 11:49:33 -0500 From: Nathan Whitehorn User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.0 To: Marius Strobl Subject: Re: Nexus improvements References: <5268332A.6080107@freebsd.org> <20131024155130.GA14293@alchemy.franken.de> In-reply-to: <20131024155130.GA14293@alchemy.franken.de> Cc: freebsd-sparc64@freebsd.org X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Oct 2013 16:49:43 -0000 On 10/24/13 10:51, Marius Strobl wrote: > On Wed, Oct 23, 2013 at 03:35:54PM -0500, Nathan Whitehorn wrote: >> I've been trying for the last few days to clean up some of our OF/FDT >> code, in particular related to reducing code duplication. There is a >> 12-year-old comment in sparc64/sparc64/nexus.c that "this code should >> get into dev/ofw to some extent". Most of the code has been moved now >> and the PowerPC nexus device has been replaced by the pieces of the >> sparc64 one that now do live in dev/ofw. The following (almost entirely >> negative) patch moves sparc64 to use it as well. Since it is just a copy >> of the sparc64 code, this should involve no functional changes, and I >> will commit it in a few days unless someone raises an objection. The >> patch is only compile tested for the time being, so hardware tests would >> be appreciated. >> >> Patch at: http://people.freebsd.org/~nwhitehorn/sparc64-nexus-unify.diff > Well, as is this patch breaks resource allocation in a strange way: > nexus0: > pcib0: mem 0x4000f600000-0x4000f6effff,0x4000f410000-0x4000f473fff irq 1983,1982 on nexus0 > panic: fire_attach: could not allocate register bank 0 Odd. The resource allocation code is an exact copy of the one from sparc64/nexus.c. I'll power up my SPARC machine and try to debug. > I didn't try to figure out what's going on as I'm still not very fond > of sharing that code across platforms. The comment you are referring to > is - as you are also pointing out - rather old and applied to a sparc64 > nexus(4) that was quite different than the current version and f. e. > didn't do resource management of its children based on OFW information. > In particular, "true" MI code shouldn't have #ifdefs with very MD code > like the one your patch would introduce. Similarly, the device exclude > lists shouldn't be shared across all platforms as one might want to > exclude a specific device whilst another does not. Having the whole > lists in unconditionally also just wastes memory on embedded machinery. There are ways around that. The main point here is to eliminate the duplication with dev/fdt, which has a similar list, for example, as well as reinventing half of the code in /sys/dev/ofw -- and that in buggy and incomplete ways. So in principle, I agree with you that other things could be wanted, but in practice they do not seem to be. The patch in general very deliberately keeps all resource allocation inside the MD code (you will note that the nexus device in sparc64 maintains all of that). The only exception has to do with interrupt numbering. SPARC doesn't seem to follow the Open Firmware interrupt-mapping standard as far as I can tell, which means that we can't use the usual platform-independent ofw_bus_map_irq(interrupt-parent, irq) call there to construct the interrupt vector ID. A few-line #ifdef for this single corner case did not seem so bad. Aside from resource allocation (which is maintained by the patch in MD code) and this nit with IRQs, the PowerPC nexus is at present a line-for-line copy of the sparc64 one. It seems a shame to maintain that duplication. > Also, switching sparc64 to use the current dev/ofw/ofw_nexus.c would > introduce some subtle differences compared to how things currently > work with the MD nexus(4). At a quick glance that would be: > o the interrupts RMAN range gets extended from IV_MAX - 1 to ~0, > which means no longer sanity checking for out-of-range interrupts, This could be restored, though I can't imagine it adds much. > o devices without at least memory resources get added as children, > while previously they were skipped. Does it harm anything to add these? I'll try to fix the bugs in any case, and then we can revisit the patch. -Nathan From owner-freebsd-sparc64@FreeBSD.ORG Fri Oct 25 07:29:06 2013 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 7B8241CF for ; Fri, 25 Oct 2013 07:29:06 +0000 (UTC) (envelope-from superbisquit@gmail.com) Received: from mail-oa0-x229.google.com (mail-oa0-x229.google.com [IPv6:2607:f8b0:4003:c02::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 4A0DD2329 for ; Fri, 25 Oct 2013 07:29:06 +0000 (UTC) Received: by mail-oa0-f41.google.com with SMTP id o9so577547oag.14 for ; Fri, 25 Oct 2013 00:29:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=VgkUuwYS4GKe6FwJh6ML2oSohA2Lx5jmSRKEDOEXANo=; b=tPuYoHj3W6KLjooryFCBb4hbfiGRAARqb9eLIqTZHXCm7bIlk3zjPcAhy+xeq+Hjh5 /SASeHuoHbSELPajarCrOI4rIfZgmPnB396mn0l3fqg+DlcIerqHj7em0+ve995F00K0 kuRtHJZD/fCcZ0JfH52kwulTnZLnmqoGaHuGvYXqX86bZHB7AvZo2YQObDZ9QEL1KKrk ZggM6B4US3YQjpNSXmLwXBRvm2SgxTWFxN7vnpFDjwffp/SJ1axgjFA7WJinugTxUH7n VCQikIhYDYHOrQhJrROqkK8OsoLH83WFbLoWx8LwCSs0OrToqL+JIGC1qbzDaKE241ro IIkw== MIME-Version: 1.0 X-Received: by 10.182.97.138 with SMTP id ea10mr72452obb.77.1382686145552; Fri, 25 Oct 2013 00:29:05 -0700 (PDT) Received: by 10.182.78.100 with HTTP; Fri, 25 Oct 2013 00:29:05 -0700 (PDT) Date: Fri, 25 Oct 2013 03:29:05 -0400 Message-ID: Subject: SunBlade1000 From: Joe Nosay To: freebsd-sparc64@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Oct 2013 07:29:06 -0000 First, is there anyone located on or near the Chesapeake Peninsula? I have two of these. One needs a cherry switch. From owner-freebsd-sparc64@FreeBSD.ORG Fri Oct 25 17:17:44 2013 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id E713A2B5; Fri, 25 Oct 2013 17:17:43 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (alchemy.franken.de [194.94.249.214]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 8DFC124A1; Fri, 25 Oct 2013 17:17:43 +0000 (UTC) Received: from alchemy.franken.de (localhost [127.0.0.1]) by alchemy.franken.de (8.14.7/8.14.7/ALCHEMY.FRANKEN.DE) with ESMTP id r9PHHfkt054100; Fri, 25 Oct 2013 19:17:41 +0200 (CEST) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.14.7/8.14.7/Submit) id r9PHHfmY054099; Fri, 25 Oct 2013 19:17:41 +0200 (CEST) (envelope-from marius) Date: Fri, 25 Oct 2013 19:17:41 +0200 From: Marius Strobl To: Nathan Whitehorn Subject: Re: Nexus improvements Message-ID: <20131025171741.GG962@alchemy.franken.de> References: <5268332A.6080107@freebsd.org> <20131024155130.GA14293@alchemy.franken.de> <52694F9D.6000705@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <52694F9D.6000705@freebsd.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-sparc64@freebsd.org X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Oct 2013 17:17:44 -0000 On Thu, Oct 24, 2013 at 11:49:33AM -0500, Nathan Whitehorn wrote: > On 10/24/13 10:51, Marius Strobl wrote: > >> > >> Patch at: http://people.freebsd.org/~nwhitehorn/sparc64-nexus-unify.diff > > Well, as is this patch breaks resource allocation in a strange way: > > nexus0: > > pcib0: mem 0x4000f600000-0x4000f6effff,0x4000f410000-0x4000f473fff irq 1983,1982 on nexus0 > > panic: fire_attach: could not allocate register bank 0 > > Odd. The resource allocation code is an exact copy of the one from > sparc64/nexus.c. I'll power up my SPARC machine and try to debug. Given that the resources actually are added correctly, I'd suspect that some of the expected parent/child relations break when deriving nexus_driver from ofw_nexus_driver but I don't get why this should have anything to do with the runtime hierarchy in the first place; this _could_ be a bug in newbus, though. > The only exception has to do with interrupt > numbering. SPARC doesn't seem to follow the Open Firmware > interrupt-mapping standard as far as I can tell That highly depends on the specific machine model; some are perfectly in line with the OFW standard, most but not all at least conform with it beneath the host-PCI-bridge level and a few are just odd here and there. The code in the tree mostly uses OFW means starting at the PCI level with some fallback and does interrupt numbering above always partially in a "manual" way, with the latter working on all models regardless of what information they provide in the respective OFW device tree. > Aside from resource allocation (which is maintained by the patch in MD > code) and this nit with IRQs, the PowerPC nexus is at present a > line-for-line copy of the sparc64 one. It seems a shame to maintain that > duplication. Well, on the other hand it's not that much additional code compared to other nexus(4) implementations that are more or less duplicated in the tree. Also, this stuff doesn't actually change that much over time. However, one thing that's currently missing on sparc64 is obtaining NUMA information; that again very likely will need additional tweaks to nexus(4) similar to what's already there for topologies involving ssm(4) given that OFW nodes representing single cores also are found in different spots in the device tree hierarchy depending on the machine model. All that said, IMO we're actually rather good at factoring out common OFW code into dev/ofw to the extent it really makes sense, apart from the fact that some FDT bits and stuff could make better (re-)use of the existing "true" OFW code, which you've already fixed recently or apparently are planning to do. > > > Also, switching sparc64 to use the current dev/ofw/ofw_nexus.c would > > introduce some subtle differences compared to how things currently > > work with the MD nexus(4). At a quick glance that would be: > > o the interrupts RMAN range gets extended from IV_MAX - 1 to ~0, > > which means no longer sanity checking for out-of-range interrupts, > > This could be restored, though I can't imagine it adds much. At least in the past such "implicit" range checks turned out to be useful when adding support for new classes of sparc64 machines. > > o devices without at least memory resources get added as children, > > while previously they were skipped. > > Does it harm anything to add these? I'll try to fix the bugs in any > case, and then we can revisit the patch. No real "harm"; it just wastes a bit of memory to have devices in the FreeBSD device tree that no driver ever will attach to and the associated message the sparc64 nexus(4) emits when detecting such even registerless devices helps to identify nodes that are better added to the exclusion list. Marius From owner-freebsd-sparc64@FreeBSD.ORG Sat Oct 26 16:28:07 2013 Return-Path: Delivered-To: sparc64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 579E09EA; Sat, 26 Oct 2013 16:28:07 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 116C12672; Sat, 26 Oct 2013 16:28:06 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r9QGS52X066248; Sat, 26 Oct 2013 12:28:05 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r9QGS5ro066245; Sat, 26 Oct 2013 16:28:05 GMT (envelope-from tinderbox@freebsd.org) Date: Sat, 26 Oct 2013 16:28:05 GMT Message-Id: <201310261628.r9QGS5ro066245@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on sparc64/sparc64 Precedence: bulk X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Oct 2013 16:28:07 -0000 TB --- 2013-10-26 15:25:08 - tinderbox 2.20 running on freebsd-current.sentex.ca TB --- 2013-10-26 15:25:08 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-10-26 15:25:08 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2013-10-26 15:25:08 - cleaning the object tree TB --- 2013-10-26 15:25:08 - /usr/local/bin/svn stat /src TB --- 2013-10-26 15:25:11 - At svn revision 257155 TB --- 2013-10-26 15:25:12 - building world TB --- 2013-10-26 15:25:12 - CROSS_BUILD_TESTING=YES TB --- 2013-10-26 15:25:12 - MAKEOBJDIRPREFIX=/obj TB --- 2013-10-26 15:25:12 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-10-26 15:25:12 - SRCCONF=/dev/null TB --- 2013-10-26 15:25:12 - TARGET=sparc64 TB --- 2013-10-26 15:25:12 - TARGET_ARCH=sparc64 TB --- 2013-10-26 15:25:12 - TZ=UTC TB --- 2013-10-26 15:25:12 - __MAKE_CONF=/dev/null TB --- 2013-10-26 15:25:12 - cd /src TB --- 2013-10-26 15:25:12 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Sat Oct 26 15:25:20 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] gzip -cn /src/usr.sbin/pciconf/pciconf.8 > pciconf.8.gz ===> usr.sbin/periodic (all) gzip -cn /src/usr.sbin/periodic/periodic.8 > periodic.8.gz ===> usr.sbin/pkg (all) cc -O2 -pipe -I/src/usr.sbin/pkg/../../contrib/libyaml/include -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -c /src/usr.sbin/pkg/pkg.c cc1: warnings being treated as errors /src/usr.sbin/pkg/pkg.c: In function 'load_public_key_buf': /src/usr.sbin/pkg/pkg.c:490: warning: cast discards qualifiers from pointer target type *** Error code 1 Stop. bmake[3]: stopped in /src/usr.sbin/pkg *** Error code 1 Stop. bmake[2]: stopped in /src/usr.sbin *** Error code 1 Stop. bmake[1]: stopped in /src *** Error code 1 Stop. bmake: stopped in /src *** Error code 1 Stop in /src. TB --- 2013-10-26 16:28:05 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-10-26 16:28:05 - ERROR: failed to build world TB --- 2013-10-26 16:28:05 - 3048.23 user 542.39 system 3777.31 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-sparc64-sparc64.full