From owner-freebsd-sparc64@FreeBSD.ORG Sun Oct 31 21:14:13 2010 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B39D1106564A for ; Sun, 31 Oct 2010 21:14:13 +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 8BF3C8FC08 for ; Sun, 31 Oct 2010 21:14:13 +0000 (UTC) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.icecube.wisc.edu (Postfix) with ESMTP id F39DB582C3; Sun, 31 Oct 2010 15:44:15 -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 sjNjVsh+0+Rm; Sun, 31 Oct 2010 15:44:15 -0500 (CDT) Received: from comporellon.tachypleus.net (unknown [76.210.66.181]) by mail.icecube.wisc.edu (Postfix) with ESMTP id A9BA1582C2; Sun, 31 Oct 2010 15:44:15 -0500 (CDT) Message-ID: <4CCDD51F.2040003@freebsd.org> Date: Sun, 31 Oct 2010 15:44:15 -0500 From: Nathan Whitehorn User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.14) Gecko/20101021 Thunderbird/3.0.9 MIME-Version: 1.0 To: freebsd-ppc@freebsd.org, freebsd-sparc64@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Review request -- splitting OF enumeration from nexus X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Oct 2010 21:14:13 -0000 Nexus on OF platforms doesn't behave like nexus on x86, which generates some periodic difficulty with cryptosoft or syscons attaching to all devices and taking over the system when someone makes a wrong assumption. I have done some work to split out OF enumeration into a new, acpi(4)-like bus called ofwbus that does all of the OF enumeration previously done by nexus(4). The patch can be found at http://people.freebsd.org/~nwhitehorn/ofwbus.diff. Doing this also provides a number of other benefits: it shares code between PowerPC and sparc64, unifies the AIM and Book-E nexus implementations on PPC, and makes it easier to have non-Open Firmware platforms on PPC (the original motivation for the work). I have tested this code with no obvious problems on a variety of Apple PPC machines and a Sun Ultra 5. More testing and comments would be much appreciated. If no has any objections, I will commit these changes in 2 weeks. -Nathan From owner-freebsd-sparc64@FreeBSD.ORG Mon Nov 1 11:07:05 2010 Return-Path: Delivered-To: freebsd-sparc64@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DADD51065674 for ; Mon, 1 Nov 2010 11:07:05 +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 C7DBC8FC15 for ; Mon, 1 Nov 2010 11:07:05 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id oA1B75bP019295 for ; Mon, 1 Nov 2010 11:07:05 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id oA1B750E019293 for freebsd-sparc64@FreeBSD.org; Mon, 1 Nov 2010 11:07:05 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 1 Nov 2010 11:07:05 GMT Message-Id: <201011011107.oA1B750E019293@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 Cc: Subject: Current problem reports assigned to freebsd-sparc64@FreeBSD.org X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Nov 2010 11:07:05 -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 -------------------------------------------------------------------------------- f sparc/145211 sparc64 [panic] Memory modified after free o sparc/142102 sparc64 [nfs] [panic] FreeBSD 8.0 kernel panics on sparc64 whe o sparc/141918 sparc64 [ehci] ehci_interrupt: unrecoverable error, controller s sparc/139134 sparc64 kernel output corruption o sparc/119244 sparc64 X11Forwarding to X11 server on sparc crashes Xorg o sparc/119240 sparc64 top has WCPU over 100% on UP system s sparc/119239 sparc64 gdb coredumps on sparc64 f sparc/108732 sparc64 ping(8) reports 14 digit time on sparc64 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/80890 sparc64 [panic] kmem_malloc(73728): kmem_map too small running o sparc/71729 sparc64 printf in kernel thread causes panic on SPARC 13 problems total. From owner-freebsd-sparc64@FreeBSD.ORG Mon Nov 1 15:20:04 2010 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 40FEE106564A; Mon, 1 Nov 2010 15:20:04 +0000 (UTC) (envelope-from john@baldwin.cx) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 0A8278FC24; Mon, 1 Nov 2010 15:20:04 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id B46B846B85; Mon, 1 Nov 2010 11:20:03 -0400 (EDT) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id CCA448A01D; Mon, 1 Nov 2010 11:20:02 -0400 (EDT) From: John Baldwin To: freebsd-ppc@freebsd.org Date: Mon, 1 Nov 2010 09:41:28 -0400 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20100819; KDE/4.4.5; amd64; ; ) References: <4CCDD51F.2040003@freebsd.org> In-Reply-To: <4CCDD51F.2040003@freebsd.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201011010941.28522.john@baldwin.cx> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Mon, 01 Nov 2010 11:20:02 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.96.3 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.9 required=4.2 tests=BAYES_00 autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on bigwig.baldwin.cx Cc: freebsd-sparc64@freebsd.org Subject: Re: Review request -- splitting OF enumeration from nexus X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Nov 2010 15:20:04 -0000 On Sunday, October 31, 2010 4:44:15 pm Nathan Whitehorn wrote: > Nexus on OF platforms doesn't behave like nexus on x86, which generates > some periodic difficulty with cryptosoft or syscons attaching to all > devices and taking over the system when someone makes a wrong > assumption. I have done some work to split out OF enumeration into a > new, acpi(4)-like bus called ofwbus that does all of the OF enumeration > previously done by nexus(4). The patch can be found at > http://people.freebsd.org/~nwhitehorn/ofwbus.diff. > > Doing this also provides a number of other benefits: it shares code > between PowerPC and sparc64, unifies the AIM and Book-E nexus > implementations on PPC, and makes it easier to have non-Open Firmware > platforms on PPC (the original motivation for the work). I have tested > this code with no obvious problems on a variety of Apple PPC machines > and a Sun Ultra 5. More testing and comments would be much appreciated. > If no has any objections, I will commit these changes in 2 weeks. Sounds good to me. It's a bit of a shame that nexus is MI. I do wonder if cryptosoft even needs a device_t at all. -- John Baldwin From owner-freebsd-sparc64@FreeBSD.ORG Mon Nov 1 15:35:04 2010 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DB500106566C for ; Mon, 1 Nov 2010 15:35:04 +0000 (UTC) (envelope-from chmeeedalf@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 625B58FC0A for ; Mon, 1 Nov 2010 15:35:04 +0000 (UTC) Received: by wyb42 with SMTP id 42so5626118wyb.13 for ; Mon, 01 Nov 2010 08:35:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; bh=UXnnATeAHq6duI3eaCIpxbyM/mH6RgAT7ia1CBzRpWo=; b=GgBGPAscETho1E75MR3dkMAawviiUz+ud4Tr3C2VMBAQ6CxyUc6KZsHJ/QMO071RQA Mplb/B2sI2A6X1hlnklkaY6nzk4l4u5m0fikkGgYYaLUg5oHQYGiby2jDvDTH3JqJTmU rcIe/R3dIi0L6YLu0Eqh1VY/kxW6MFBkhe9KE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=hI6nNLmgjWDUwLb7whPShDAzEvL1bjMk9g3fZDyEiERXk41Mj/zmx3bANGobBgJkvj 4yLwpx+3kXXdhjN8bqLEvuK9xvg0lH+cTjj4yp1FnASkFBCYirDBtsXi7vkxfTw2Wq9/ jaCtOsP4ffWbKplCgr1qwAVeG25ZD/Ef4avKY= MIME-Version: 1.0 Received: by 10.216.159.195 with SMTP id s45mr12631896wek.43.1288623889128; Mon, 01 Nov 2010 08:04:49 -0700 (PDT) Sender: chmeeedalf@gmail.com Received: by 10.216.49.201 with HTTP; Mon, 1 Nov 2010 08:04:49 -0700 (PDT) In-Reply-To: <4CCDD51F.2040003@freebsd.org> References: <4CCDD51F.2040003@freebsd.org> Date: Mon, 1 Nov 2010 11:04:49 -0400 X-Google-Sender-Auth: GxOsXTEGlQEkMiJzBem3u2od3aQ Message-ID: From: Justin Hibbits To: Nathan Whitehorn Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-sparc64@freebsd.org, freebsd-ppc@freebsd.org Subject: Re: Review request -- splitting OF enumeration from nexus X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Nov 2010 15:35:04 -0000 On Sun, Oct 31, 2010 at 4:44 PM, Nathan Whitehorn wrote: > Nexus on OF platforms doesn't behave like nexus on x86, which generates > some periodic difficulty with cryptosoft or syscons attaching to all devices > and taking over the system when someone makes a wrong assumption. I have > done some work to split out OF enumeration into a new, acpi(4)-like bus > called ofwbus that does all of the OF enumeration previously done by > nexus(4). The patch can be found at > http://people.freebsd.org/~nwhitehorn/ofwbus.diff. > > Doing this also provides a number of other benefits: it shares code between > PowerPC and sparc64, unifies the AIM and Book-E nexus implementations on > PPC, and makes it easier to have non-Open Firmware platforms on PPC (the > original motivation for the work). I have tested this code with no obvious > problems on a variety of Apple PPC machines and a Sun Ultra 5. More testing > and comments would be much appreciated. If no has any objections, I will > commit these changes in 2 weeks. > -Nathan > Building world now, and will test when I get home this evening. A note to others: powerpc/powerpc/nexus.c is a resurrected file, so I needed to copy it from powerpc/aim/nexus.c before the patch would apply. - Justin From owner-freebsd-sparc64@FreeBSD.ORG Tue Nov 2 11:53:33 2010 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C1AA51065672 for ; Tue, 2 Nov 2010 11:53:33 +0000 (UTC) (envelope-from cyberratz@doom-labs.net) Received: from diabolo.doom-labs.net (diabolo.doom-labs.net [83.120.0.115]) by mx1.freebsd.org (Postfix) with ESMTP id 40D308FC08 for ; Tue, 2 Nov 2010 11:53:32 +0000 (UTC) Received: from [192.168.0.10] (dslb-094-223-138-019.pools.arcor-ip.net [94.223.138.19]) (authenticated bits=0) by diabolo.doom-labs.net (8.14.4/8.14.4/dli-1.0.3) with ESMTP id oA2BQXhK093458 (version=TLSv1/SSLv3 cipher=DHE-DSS-CAMELLIA256-SHA bits=256 verify=NO) for ; Tue, 2 Nov 2010 12:26:34 +0100 (CET) (envelope-from cyberratz@doom-labs.net) Message-ID: <4CCFF565.7060503@doom-labs.net> Date: Tue, 02 Nov 2010 12:26:29 +0100 From: "Ekki 'CyberRatz' Gehm" Organization: Doom-Labs Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: freebsd-sparc64@freebsd.org X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Subject: Hardware Monitor for E420R X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Nov 2010 11:53:33 -0000 HeyHo! I installed FBSD to an Enterprise 420R lately and it runs great! Now I was wondering if there is a posibility to read out hardware stats such as core temp etc. (eg something like healthd on x86 platforms). Unfortunately I dont know if it is supported at all. Is there something in the portstree for this issue? I was trying to find s.th. but I acc. didn't find anything. THX for any tipps :-) Cheers, Ekki From owner-freebsd-sparc64@FreeBSD.ORG Tue Nov 2 13:13:21 2010 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 046BD1065679; Tue, 2 Nov 2010 13:13:20 +0000 (UTC) (envelope-from chmeeedalf@gmail.com) Received: from mail-ey0-f182.google.com (mail-ey0-f182.google.com [209.85.215.182]) by mx1.freebsd.org (Postfix) with ESMTP id 283CD8FC1B; Tue, 2 Nov 2010 13:13:19 +0000 (UTC) Received: by eyb7 with SMTP id 7so3429658eyb.13 for ; Tue, 02 Nov 2010 06:13:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; bh=WHo2LKt1Ue2xu7HnNnCB3/BvskOGAufs7EKOLjguWMc=; b=W8udFjMFvO6oDvbDBGSZjZ5QhH5dkuaKxfvNY7s2Xo3vlRrNbIQLHrCWFNg2tndZ5H 9pORFCXEa3A383EEFgzI2cEDhuqJQ83WtJijGPtUcveyxe7xgtO8+/eEaVXqA1otkiQi JMSYRrcN512JcnfI+tnA1vSpnEQhlwimylRP0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=S/fg6UyTwEe5pMrkrPGj2aJh/EVw6/OvKSLgp0nvSdgM0WBW52AoE4JNA5OhgK2Ve/ bzTluIqf/KawwcaFJSyOW+jwJ+85jG4jp4x8mFHD9li4frVaoq4isbqNJAkaUrg2nC/X Tksb6ZVUP1qotYHLUUPSO72ePgm+1ivpB4GAI= MIME-Version: 1.0 Received: by 10.216.168.194 with SMTP id k44mr9826766wel.58.1288703598421; Tue, 02 Nov 2010 06:13:18 -0700 (PDT) Sender: chmeeedalf@gmail.com Received: by 10.216.49.201 with HTTP; Tue, 2 Nov 2010 06:13:18 -0700 (PDT) In-Reply-To: References: <4CCDD51F.2040003@freebsd.org> Date: Tue, 2 Nov 2010 09:13:18 -0400 X-Google-Sender-Auth: WHoNvGBieQ6FYJNJIv0GwoP25FA Message-ID: From: Justin Hibbits To: Nathan Whitehorn Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-sparc64@freebsd.org, freebsd-ppc@freebsd.org Subject: Re: Review request -- splitting OF enumeration from nexus X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Nov 2010 13:13:21 -0000 On Mon, Nov 1, 2010 at 11:04 AM, Justin Hibbits wrote: > On Sun, Oct 31, 2010 at 4:44 PM, Nathan Whitehorn wrote: > >> Nexus on OF platforms doesn't behave like nexus on x86, which generates >> some periodic difficulty with cryptosoft or syscons attaching to all devices >> and taking over the system when someone makes a wrong assumption. I have >> done some work to split out OF enumeration into a new, acpi(4)-like bus >> called ofwbus that does all of the OF enumeration previously done by >> nexus(4). The patch can be found at >> http://people.freebsd.org/~nwhitehorn/ofwbus.diff. >> >> Doing this also provides a number of other benefits: it shares code >> between PowerPC and sparc64, unifies the AIM and Book-E nexus >> implementations on PPC, and makes it easier to have non-Open Firmware >> platforms on PPC (the original motivation for the work). I have tested this >> code with no obvious problems on a variety of Apple PPC machines and a Sun >> Ultra 5. More testing and comments would be much appreciated. If no has any >> objections, I will commit these changes in 2 weeks. >> -Nathan >> > > Building world now, and will test when I get home this evening. > > A note to others: powerpc/powerpc/nexus.c is a resurrected file, so I > needed to copy it from powerpc/aim/nexus.c before the patch would apply. > > - Justin > > It's been up for 13 hours now with no problems. Machine: G4 1.25GHz MDD. - Justin From owner-freebsd-sparc64@FreeBSD.ORG Tue Nov 2 20:06:08 2010 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 49598106564A for ; Tue, 2 Nov 2010 20:06:08 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (alchemy.franken.de [194.94.249.214]) by mx1.freebsd.org (Postfix) with ESMTP id D0F9D8FC1A for ; Tue, 2 Nov 2010 20:06:07 +0000 (UTC) Received: from alchemy.franken.de (localhost [127.0.0.1]) by alchemy.franken.de (8.14.4/8.14.4/ALCHEMY.FRANKEN.DE) with ESMTP id oA2K59li020999; Tue, 2 Nov 2010 21:05:09 +0100 (CET) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.14.4/8.14.4/Submit) id oA2K59AS020998; Tue, 2 Nov 2010 21:05:09 +0100 (CET) (envelope-from marius) Date: Tue, 2 Nov 2010 21:05:09 +0100 From: Marius Strobl To: "Ekki 'CyberRatz' Gehm" Message-ID: <20101102200509.GA20864@alchemy.franken.de> References: <4CCFF565.7060503@doom-labs.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4CCFF565.7060503@doom-labs.net> User-Agent: Mutt/1.4.2.3i Cc: freebsd-sparc64@freebsd.org Subject: Re: Hardware Monitor for E420R X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Nov 2010 20:06:08 -0000 On Tue, Nov 02, 2010 at 12:26:29PM +0100, Ekki 'CyberRatz' Gehm wrote: > HeyHo! > > I installed FBSD to an Enterprise 420R lately and it runs great! Now I > was wondering if there is a posibility to read out hardware stats such > as core temp etc. (eg something like healthd on x86 platforms). > Unfortunately I dont know if it is supported at all. > > Is there something in the portstree for this issue? I was trying to find > s.th. but I acc. didn't find anything. > Unlike as in the x86 world there's no common interface for querying such information on sun4u machines but rather they are accessible via model-specific (apparently Sun had no need to make the life of third party developers easy with either their hardware or Solaris and generally liked to re-invent the wheel) solutions if implemented at all, which FreeBSD supports none so far. Partly this is due to the amount of work involved to make this work and also partly due to the fact that FreeBSD lacks an generic actuator- and sensors-framework (one actually shouldn't need to re-implement access to sensors, fan-control subroutines etc for every model) to build upon. However, typically the ALOM, LOM, ILOM, RSC etc management cards also allow easy access to such information via the `show environment` and `showenvironment` commands respectively, I'm not sure E420R uses one of these though. Marius From owner-freebsd-sparc64@FreeBSD.ORG Fri Nov 5 11:07:30 2010 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 733961065670; Fri, 5 Nov 2010 11:07:30 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (alchemy.franken.de [194.94.249.214]) by mx1.freebsd.org (Postfix) with ESMTP id C613F8FC14; Fri, 5 Nov 2010 11:07:29 +0000 (UTC) Received: from alchemy.franken.de (localhost [127.0.0.1]) by alchemy.franken.de (8.14.4/8.14.4/ALCHEMY.FRANKEN.DE) with ESMTP id oA5B7SGa065591; Fri, 5 Nov 2010 12:07:28 +0100 (CET) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.14.4/8.14.4/Submit) id oA5B7S0J065590; Fri, 5 Nov 2010 12:07:28 +0100 (CET) (envelope-from marius) Date: Fri, 5 Nov 2010 12:07:28 +0100 From: Marius Strobl To: Nathan Whitehorn Message-ID: <20101105110728.GA65518@alchemy.franken.de> References: <4CCDD51F.2040003@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4CCDD51F.2040003@freebsd.org> User-Agent: Mutt/1.4.2.3i Cc: freebsd-sparc64@freebsd.org, freebsd-ppc@freebsd.org Subject: Re: Review request -- splitting OF enumeration from nexus X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Nov 2010 11:07:30 -0000 On Sun, Oct 31, 2010 at 03:44:15PM -0500, Nathan Whitehorn wrote: > Nexus on OF platforms doesn't behave like nexus on x86, which generates > some periodic difficulty with cryptosoft or syscons attaching to all > devices and taking over the system when someone makes a wrong > assumption. I think this is an exaggeration of the problem; the only relevant difference in this regard should be that on x86 there are no (unattached) non-pseudo-devices on the nexus, while on powerpc and sparc64 (apparently this also applies to the embedded architectures though) there are real devices where a buggy pseudo-driver like cryptosoft(4) has a chance to attach to. AFAICT cryptosoft(4) also is the only MI driver suffering from this and can be easily fixed by letting it add its pseudo-device with a specific unit number and return BUS_PROBE_NOWILDCARD. The syscons(4) front-end you are referring to is a powerpc MD part and the sparc64 counterpart never had that problem. > I have done some work to split out OF enumeration into a > new, acpi(4)-like bus called ofwbus that does all of the OF enumeration > previously done by nexus(4). The patch can be found at > http://people.freebsd.org/~nwhitehorn/ofwbus.diff. > > Doing this also provides a number of other benefits: it shares code > between PowerPC and sparc64, unifies the AIM and Book-E nexus > implementations on PPC, and makes it easier to have non-Open Firmware > platforms on PPC (the original motivation for the work). I have tested > this code with no obvious problems on a variety of Apple PPC machines > and a Sun Ultra 5. More testing and comments would be much appreciated. > If no has any objections, I will commit these changes in 2 weeks. To be honest I don't like the approach of factoring out the OF enumeration to dev/ofw the way it is done for the following reasons: o Currently we perfectly recreate the hierarchy of the OF device tree in the kernel, where the OF root device is represented by the root node, the OF nexus by nexus(4) and so forth. With ofwbus(4) in between we break this shadowing. Granted, this is somewhat a cosmetic issue, but still having the same hierarchy IMO is a nice feature as other code like for example the CPU/core enumeration code (which has to work before bus and device enumeration is done) still has to work with the OF device tree so basically one has to deal with both hierarchies in the kernel. o It shoves way too much MD-knowledge into dev/ofw, f.e. the device exclude lists (which even might be contradicting across platforms, i.e. every time one adds device for one architecture one would have to check whether there isn't a vital device of the same name or type on the others) and the interrupt bits (f.e. sun4v yet again would need something different there). o Besides adding some style bugs the patch also has several obvious functional ones, f.e. the type-based exclude list of sparc64 got lost, the former nexus(4) front-end of ebus(4) now tries to attach to ofwdump(4)[sic] and for sparc64 (as well as for sun4v) the default for the number of address-cells when no corresponding property exists would need to be 2 instead of 1 (on sparc64 these properties actually are missing occasionally). Also due to the sheer complexity I'm not sure from the patch whether ssm(4), which previously inherited from nexus(4), still works correctly. What this all boils down to is that due to the great variety of busses and devices on sparc64 and how they may hang off from each other in different ways this patch would need to be tested on all sun4u models FreeBSD supports so far in order to shake out all problems with corner cases of the patch and fof irmware versions (Solaris probably doesn't duplicated most of the equivalents for every machine model without a reason), several of which I only had temporary access to. Put differently, if you want to factor this out into dev/ofw for powerpc feel free to do so but please find a way to keep the MI part really MI so that device exclude lists, interrupt bits, cell defaults etc remain in MD locations (f.e. by supplying macros for these in MD headers or for the interrupt bits maybe and also a function in the MD code) and please don't switch sparc64 to it. IMO this just would need a lot of work to stabilize it there with no real net gain. Regarding reducing code duplication on sparc64 I'd rather prefer to put all relevant OF knowledge into nexus(4) and inherit from there like I've started to do with ssm(4) (but what probably should also work with f.e. central(4), fhc(4) and upa(4) but not so easily with sbus(4)). But unfortunately retro- fitting changes in the bus support always is a PITA on sparc64 due to the significant differences in peripherals between machine models and in firmware anomalies between different versions for the same model. Marius From owner-freebsd-sparc64@FreeBSD.ORG Fri Nov 5 13:02:51 2010 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 01B3F106564A; Fri, 5 Nov 2010 13:02:51 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id C2E4E8FC08; Fri, 5 Nov 2010 13:02:50 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 6858946B09; Fri, 5 Nov 2010 09:02:50 -0400 (EDT) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 7CA428A01D; Fri, 5 Nov 2010 09:02:49 -0400 (EDT) From: John Baldwin To: freebsd-sparc64@freebsd.org Date: Fri, 5 Nov 2010 09:02:25 -0400 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20100819; KDE/4.4.5; amd64; ; ) References: <4CCDD51F.2040003@freebsd.org> <20101105110728.GA65518@alchemy.franken.de> In-Reply-To: <20101105110728.GA65518@alchemy.franken.de> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201011050902.25879.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Fri, 05 Nov 2010 09:02:49 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.96.3 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.9 required=4.2 tests=BAYES_00 autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on bigwig.baldwin.cx Cc: freebsd-ppc@freebsd.org, Marius Strobl Subject: Re: Review request -- splitting OF enumeration from nexus X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Nov 2010 13:02:51 -0000 On Friday, November 05, 2010 7:07:28 am Marius Strobl wrote: > On Sun, Oct 31, 2010 at 03:44:15PM -0500, Nathan Whitehorn wrote: > > Nexus on OF platforms doesn't behave like nexus on x86, which generates > > some periodic difficulty with cryptosoft or syscons attaching to all > > devices and taking over the system when someone makes a wrong > > assumption. > > I think this is an exaggeration of the problem; the only relevant > difference in this regard should be that on x86 there are no > (unattached) non-pseudo-devices on the nexus, while on powerpc and > sparc64 (apparently this also applies to the embedded architectures > though) there are real devices where a buggy pseudo-driver like > cryptosoft(4) has a chance to attach to. AFAICT cryptosoft(4) also > is the only MI driver suffering from this and can be easily fixed > by letting it add its pseudo-device with a specific unit number and > return BUS_PROBE_NOWILDCARD. The syscons(4) front-end you are > referring to is a powerpc MD part and the sparc64 counterpart never > had that problem. Actually, I think the fix for cryptosoft is that it doesn't belong in new_bus at all. It simply needs to supply a kobj that implements the crypto-related methods, but all the new-bus stuff isn't actually needed. -- John Baldwin From owner-freebsd-sparc64@FreeBSD.ORG Fri Nov 5 14:43:39 2010 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A8BF0106566C; Fri, 5 Nov 2010 14:43:39 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (alchemy.franken.de [194.94.249.214]) by mx1.freebsd.org (Postfix) with ESMTP id 36EC68FC12; Fri, 5 Nov 2010 14:43:38 +0000 (UTC) Received: from alchemy.franken.de (localhost [127.0.0.1]) by alchemy.franken.de (8.14.4/8.14.4/ALCHEMY.FRANKEN.DE) with ESMTP id oA5Ehb36067039; Fri, 5 Nov 2010 15:43:37 +0100 (CET) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.14.4/8.14.4/Submit) id oA5EhbUm067038; Fri, 5 Nov 2010 15:43:37 +0100 (CET) (envelope-from marius) Date: Fri, 5 Nov 2010 15:43:37 +0100 From: Marius Strobl To: John Baldwin Message-ID: <20101105144337.GE5289@alchemy.franken.de> References: <4CCDD51F.2040003@freebsd.org> <20101105110728.GA65518@alchemy.franken.de> <201011050902.25879.jhb@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201011050902.25879.jhb@freebsd.org> User-Agent: Mutt/1.4.2.3i Cc: freebsd-ppc@freebsd.org, freebsd-sparc64@freebsd.org Subject: Re: Review request -- splitting OF enumeration from nexus X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Nov 2010 14:43:39 -0000 On Fri, Nov 05, 2010 at 09:02:25AM -0400, John Baldwin wrote: > On Friday, November 05, 2010 7:07:28 am Marius Strobl wrote: > > On Sun, Oct 31, 2010 at 03:44:15PM -0500, Nathan Whitehorn wrote: > > > Nexus on OF platforms doesn't behave like nexus on x86, which generates > > > some periodic difficulty with cryptosoft or syscons attaching to all > > > devices and taking over the system when someone makes a wrong > > > assumption. > > > > I think this is an exaggeration of the problem; the only relevant > > difference in this regard should be that on x86 there are no > > (unattached) non-pseudo-devices on the nexus, while on powerpc and > > sparc64 (apparently this also applies to the embedded architectures > > though) there are real devices where a buggy pseudo-driver like > > cryptosoft(4) has a chance to attach to. AFAICT cryptosoft(4) also > > is the only MI driver suffering from this and can be easily fixed > > by letting it add its pseudo-device with a specific unit number and > > return BUS_PROBE_NOWILDCARD. The syscons(4) front-end you are > > referring to is a powerpc MD part and the sparc64 counterpart never > > had that problem. > > Actually, I think the fix for cryptosoft is that it doesn't belong in new_bus > at all. It simply needs to supply a kobj that implements the crypto-related > methods, but all the new-bus stuff isn't actually needed. > Likely that would be the best fix but AFAICT that unfortunately isn't exactly straightforward as crypto_get_driverid() and the rest of crypto(9) apparently inherently expect a valid device_t (probably due to the fact it was mainly intended for hardware crypto devices). I'm not sure it's worth fixing that also or do you see a way that gets rid of the device_t dependency and doesn't break the KPI? Marius