From owner-svn-src-all@FreeBSD.ORG Sun May 16 21:38:24 2010 Return-Path: Delivered-To: svn-src-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 079721065670; Sun, 16 May 2010 21:38:24 +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 737838FC0C; Sun, 16 May 2010 21:38:23 +0000 (UTC) Received: from alchemy.franken.de (localhost [127.0.0.1]) by alchemy.franken.de (8.14.3/8.14.3/ALCHEMY.FRANKEN.DE) with ESMTP id o4GLcMTP029152; Sun, 16 May 2010 23:38:22 +0200 (CEST) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.14.3/8.14.3/Submit) id o4GLcMIh029151; Sun, 16 May 2010 23:38:22 +0200 (CEST) (envelope-from marius) Date: Sun, 16 May 2010 23:38:22 +0200 From: Marius Strobl To: Nathan Whitehorn Message-ID: <20100516213822.GA49967@alchemy.franken.de> References: <201005161557.o4GFv0Lf046659@svn.freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201005161557.o4GFv0Lf046659@svn.freebsd.org> User-Agent: Mutt/1.4.2.3i Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org Subject: Re: svn commit: r208152 - in head/sys: dev/ofw powerpc/aim powerpc/ofw X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 May 2010 21:38:24 -0000 On Sun, May 16, 2010 at 03:57:00PM +0000, Nathan Whitehorn wrote: > Author: nwhitehorn > Date: Sun May 16 15:56:59 2010 > New Revision: 208152 > URL: http://svn.freebsd.org/changeset/base/208152 > > Log: > On PowerMac11,2 and (presumably) PowerMac12,1, we need to quiesce the > firmware in order to take over control of the SMU. Without doing this, > the firmware background process doing fan control will run amok as we > take over the system and crash the management chip. > > This is limited to these two machines because our kernel is heavily > dependent on firmware accesses, and so quiescing firmware can cause > nasty problems. > Given that the "quiesce" service isn't part of the Open Firmware standard nor of one of its supplements as far as I can see and given this service isn't available on sun4u I'd prefer this implementation to be entirely moved to MD parts instead (similar to the "SUNW," services which we keep MD). Marius