From sacadmin Fri Dec 14 12:35:23 2007 Received: from noho.sfbay.sun.com (noho [10.6.92.101]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lBEKZNL3014024; Fri, 14 Dec 2007 12:35:23 -0800 (PST) Received: from noho.sfbay.sun.com (localhost [127.0.0.1]) by noho.sfbay.sun.com (8.13.7+Sun/8.13.7) with ESMTP id lBEKYQ96008809; Fri, 14 Dec 2007 12:34:26 -0800 (PST) Received: (from dmk@localhost) by noho.sfbay.sun.com (8.13.7+Sun/8.13.7/Submit) id lBEKYQFG008805; Fri, 14 Dec 2007 12:34:26 -0800 (PST) Date: Fri, 14 Dec 2007 12:34:26 -0800 (PST) From: David Kahn Message-Id: <200712142034.lBEKYQFG008805@noho.sfbay.sun.com> To: FWARC@sac.sfbay.sun.com Cc: David.Arneson@noho.sfbay.sun.com Subject: Error Notification Package [FWARC/2007/693 FastTrack timeout 12/21/2008] Status: RO Content-Length: 7221 #pragma ident "@(#)error-notify.txt 1.7 07/12/14 SMI" 1. Introduction 1.1. Project/Component Working Name: Error Notification package for FCode drivers to notify faults to base OpenBoot or platform specific code. 1.2. Name of Document Author/Supplier: David Arneson David Kahn 1.3. Date of This Document: 12/14/07 1.4. Name of Major Document Customer(s)/Consumer(s): 1.4.1. The PAC or CPT you expect to review your project: 1.4.2. The ARC(s) you expect to review your project: FWARC 1.4.3. The Director/VP who is "Sponsoring" this project: Mike Sanfratello 1.4.4. The name of your business unit: Common Software 1.5. Email Aliases: 1.5.1. Responsible Manager: mary.vigil@Sun.Com 1.5.2. Responsible Engineer: david.arneson@sun.com 1.5.3. Marketing Manager: 1.5.4. Interest List: OPL_sw_obp@sun.com 2. Project Summary 2.1. Project Description: This case defines new interfaces that allow FCode drivers to notify OpenBoot or platform specific code about errors that have been detected during bus probes or other operations. 2.2. Risks and Assumptions: None. 3. Business Summary 3.1. Problem Area: OpenBoot for OPL platforms implement support to degrade a device if a fault is detected during the probe phase. Other future platforms will implement error handling during probing such that ASR interfaces are used to mark devices as offline/failed if they fail during probing. In general, the bus specific probe code in OBP needs to be hardened and deal with failures without bringing down the entire system in order to provide better service to customers. How a platform deals with a probe failure should continue to be platform specific policy, but, in general, the framework needs work to support different solutions perhaps with policy input that don't just result in the ok prompt after a probe failure. The current implementation handles error notification through use of a byte-load-hook that is used for notification of errors while the fcode is being evaluated. However, a fair amount of probing of registers and expansion ROM can occur while the device node is being installed in the device tree, and failures in that code are not currently "caught" properly, and there's no notification interface for errors during this phase. Note that byte-load-hook is implemented in base OBP and is not an interface exported to fcode drivers. In the current implementation, if a device fails during probe, rather than remove and degrade the failed PCI device, the parent device is marked as failed and removed before restarting the probe process. See CR 6498780. 3.2. Market/Requester: CR 6498780 3.3. Business Justification: CR 6498780 3.4. Competitive Analysis: CR 6498780 3.5. Opportunity Window/Exposure: CR 6498780 3.6. How will you know when you are done?: When code changes are integrated in 4.x and 4.24 gates, CR 6498780 is closed and verified. 4. Technical Description: 4.1 Overview This case defines new interfaces that allow bus specific probe code to report error conditions to anybody interested in getting notified when the error occurs. OPL platforms implement support to remove a device if a fault is detected when probing that device. Due to the current implementation, certain probe errors are reported to the current notification methods (byte-load-hook, only on certain platform implementations) as if the parent node failed. To address this problem the probe code (root complex FCode driver) needs the ability to catch and report errors to anybody interested in getting notification of a probe error, with the correct context and information necessary to identify the device that failed. This project defines a new error notification package so that the FCode drivers can notify faults to the base OpenBoot. It defines package methods to set and get an error handler with the error notification package. 4.1.1. Package Name "SUNW,probe-error-handler" 4.1.2. Package Methods 4.1.2.1. Package Specific Methods 4.1.2.1.1. set-probe-error-handler set-probe-error-handler ( error-handler-xt -- error-handler-xt' ) Set the current probe error handler to error-handler-xt. Return the previous error handler in error-handler-xt'. To unregister an error-handler-xt, the calling code can call this method with the return value from the original call to this method. Code that wants to be notified of an error, should call this method prior to probing any specific bus hierarchy. Semantics of error-handler-xt: error-handler-xt ( unit-addr-buf, unit-addr-len -- ) error-handler-xt is invoked when a probe error is caught by any bus specific probing code that implements error notification. unit-addr-buf, unit-addr-len contains a string (not NUL terminated) describing the unit address of the child that failed the probe. The format of the text string is bus-specific. At the time that error-handler-xt is called, the current instance will be the instance that failed. Thus, my-self is the failed instance, and the current package and parent package can be derived from the value of my-self. The parent package and the child unit address is sufficient to identify the device that failed. Default behavior of error-handler-xt: The default behavior of error-handler-xt provided by the package is effectively an abort" with a text string that identifies the failed component. Platform specific code can provide it's own default handler using the methods described in this document. 4.1.2.1.2. get-probe-error-handler get-probe-error-handler ( -- error-handler-xt ) Returns the current error-handler-xt at the time of the call. See 4.1.2.1.1. for the semantics of error-handler-xt. 4.1.2.2. Standard Package Methods 4.1.2.2.1. open open ( -- true ) Specifies the open method for the package. This will always return true. 4.1.2.2.2. close close ( -- ) Specifies the close method for the package. 4.2 Interface Table Imported Interfaces Interface Classification Comments ------------------------------------------------------------------- "open" Standard open method "close" Standard Close method Exported Interfaces: Interface Classification Comments ------------------------------------------------------------------- set-probe-error-handler Uncommitted package specific method get-probe-error-handler Uncommitted package specific method error-handler-xt Uncommitted form and behavior of the error handler. "SUNW,probe-error-handler" Uncommitted Package name 5. Reference Documents: IEEE Standard 1275 CR 6498780 6. Resources and Schedule: 6.1. Projected Availability: October 2007. 6.2. Cost of Effort: 10 days. 6.3. Cost of Capital Resources: 1 engineer. 6.4. Steering Committee requested information 6.4.1. Consolidation C-team Name: sysfw 6.5. ARC review type: FastTrack 6.6. ARC Exposure: open 7. Prototype Availability: 7.1. Prototype Availability: Now. 7.2. Prototype Cost: 10 days. From sacadmin Fri Dec 14 12:58:46 2007 Received: from dtmail.sfbay.sun.com (pkg [129.146.90.56]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lBEKwk6M014459 for ; Fri, 14 Dec 2007 12:58:46 -0800 (PST) Received: from [192.168.0.6] (noho [10.6.92.101]) by dtmail.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lBEKwjh1014257; Fri, 14 Dec 2007 12:58:45 -0800 (PST) Message-ID: <4762EE83.9070805@sun.com> Date: Fri, 14 Dec 2007 12:58:43 -0800 From: David Kahn User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: FWARC@sac.sfbay.sun.com CC: David.Arneson@sun.com Subject: Re: Error Notification Package [FWARC/2007/693 FastTrack timeout 12/21/2008] Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Status: RO Content-Length: 940 This case creates an optional package with defined methods and suggests a framework for how OBP might implement platform specific bus probe error handlers in the future. (For example, on sun4v, we might implement sun4v-specific error handlers that use the ASR interfaces and continue to probe the remaining devices.) This case does not require or suggest any platform-specific implementation of error handlers. The main purpose of this case is to provide a generic error notification package for pci bus probe errors for OPL platforms. This case replaces 2007/543, which was withdrawn after some discussion and objection by FWARC members. The package is optional. Use of the package is optional. (platform specific requirements dictate if the package is implemented and used.) The interface table and all the technical details are in the one-pager. The project seeks a minor/patch binding for OBP in the sysfw consolidation. -David From sacadmin Wed Jan 2 09:39:51 2008 Received: from noho.sfbay.sun.com (noho [10.6.92.101]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m02HdpeK000566 for ; Wed, 2 Jan 2008 09:39:51 -0800 (PST) Received: from noho.sfbay.sun.com (localhost [127.0.0.1]) by noho.sfbay.sun.com (8.13.7+Sun/8.13.7) with ESMTP id m02HcsMD015129; Wed, 2 Jan 2008 09:38:54 -0800 (PST) Received: (from dmk@localhost) by noho.sfbay.sun.com (8.13.7+Sun/8.13.7/Submit) id m02HcsBS015128; Wed, 2 Jan 2008 09:38:54 -0800 (PST) Date: Wed, 2 Jan 2008 09:38:54 -0800 (PST) From: David Kahn Message-Id: <200801021738.m02HcsBS015128@noho.sfbay.sun.com> To: David.Kahn@sun.com, FWARC@sac.sfbay.sun.com Subject: Re: Error Notification Package [FWARC/2007/693 FastTrack timeout 12/21/2008] Cc: David.Arneson@sun.com Status: RO Content-Length: 150 >The project seeks a minor/patch binding >for OBP in the sysfw consolidation. This fast-track case timed out on 12/21/2007 and is approved. -David From sacadmin Thu Jan 3 00:05:54 2008 Received: from zion.sfbay.sun.com (zion [129.146.17.75]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m0385sme022218 for ; Thu, 3 Jan 2008 00:05:54 -0800 (PST) Received: from zion.sfbay.sun.com (localhost [127.0.0.1]) by zion.sfbay.sun.com (8.14.2+Sun/8.14.2) with ESMTP id m0385mDK246291; Thu, 3 Jan 2008 08:05:48 GMT Received: (from mws@localhost) by zion.sfbay.sun.com (8.14.2+Sun/8.14.2/Submit) id m0385mD4246290; Thu, 3 Jan 2008 00:05:48 -0800 (PST) From: Michael Shapiro Message-Id: <200801030805.m0385mD4246290@zion.sfbay.sun.com> Subject: Re: Error Notification Package [FWARC/2007/693 FastTrack timeout 12/21/2008] In-Reply-To: <200801021738.m02HcsBS015128@noho.sfbay.sun.com> from David Kahn at "Jan 2, 2008 09:38:54 am" To: dmk@noho.sfbay.sun.com (David Kahn) Date: Thu, 3 Jan 2008 00:05:48 -0800 (PST) Cc: David.Kahn@sun.com, FWARC@sac.sfbay.sun.com, David.Arneson@sun.com X-Mailer: ELM [version 2.4ME+ PL31H (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: RO Content-Length: 305 > >The project seeks a minor/patch binding > >for OBP in the sysfw consolidation. > > This fast-track case timed out on 12/21/2007 and is > approved. > > -David How does this implementation connect to FMA on the given platform? -Mike -- Mike Shapiro, Solaris Kernel Development. blogs.sun.com/mws/ From sacadmin Thu Jan 3 09:40:58 2008 Received: from dm-sfbay-01.sfbay.sun.com (dm-sfbay-01 [129.145.155.118]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m03HewER029678 for ; Thu, 3 Jan 2008 09:40:58 -0800 (PST) Received: from brmea-mail-1.sun.com (brmea-mail-1.Sun.COM [192.18.98.31]) by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m03Hew7h026239 for ; Thu, 3 Jan 2008 09:40:58 -0800 (PST) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m03Hevuv018480 for ; Thu, 3 Jan 2008 17:40:57 GMT Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JU200C01V8BDU00@mail-amer.sun.com> (original mail from David.Arneson@Sun.COM) for FWARC@sac.sfbay.sun.com; Thu, 03 Jan 2008 10:40:57 -0700 (MST) Received: from [129.148.9.173] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JU200LPOX3U7240@mail-amer.sun.com>; Thu, 03 Jan 2008 10:40:42 -0700 (MST) Date: Thu, 03 Jan 2008 12:40:41 -0500 From: David Arneson Subject: Re: Error Notification Package [FWARC/2007/693 FastTrack timeout 12/21/2008] In-reply-to: <200801030805.m0385mD4246290@zion.sfbay.sun.com> Sender: David.Arneson@sun.com To: Michael Shapiro Cc: David.Kahn@sun.com, FWARC@sac.sfbay.sun.com Reply-to: David.Arneson@sun.com Message-id: <477D1E19.90306@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=US-ASCII Content-transfer-encoding: 7BIT References: <200801030805.m0385mD4246290@zion.sfbay.sun.com> User-Agent: Thunderbird 2.0.0.6 (X11/20070802) Status: RO Content-Length: 970 Mike, I do not think this will have any impact on FMA for OPL. The way this is used it provides a way to report errors that are detected during PCI probing inside OBP. Previously if an error occurred early in the OBP probe cycle OBP would be unable to determine the correct device that caused the problem. It would therefore degrade the parent, remove it from the system. This may take out a number of good devices including boot disk etc. Using the error notification package OBP now has a way to report errors that occur early during the PCI probe and therefore degrade the correct offending device. This also makes the OBP PCI probe code more error tolerant. Michael Shapiro wrote: >>> The project seeks a minor/patch binding >>> for OBP in the sysfw consolidation. >>> >> This fast-track case timed out on 12/21/2007 and is >> approved. >> >> -David >> > > How does this implementation connect to FMA on the given platform? > > -Mike > > From sacadmin Thu Jan 3 10:09:52 2008 Received: from zion.sfbay.sun.com (zion [129.146.17.75]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m03I9qqa000307 for ; Thu, 3 Jan 2008 10:09:52 -0800 (PST) Received: from zion.sfbay.sun.com (localhost [127.0.0.1]) by zion.sfbay.sun.com (8.14.2+Sun/8.14.2) with ESMTP id m03I9kvm251584; Thu, 3 Jan 2008 18:09:46 GMT Received: (from mws@localhost) by zion.sfbay.sun.com (8.14.2+Sun/8.14.2/Submit) id m03I9k8S251583; Thu, 3 Jan 2008 10:09:46 -0800 (PST) Date: Thu, 3 Jan 2008 10:09:45 -0800 From: Mike Shapiro To: David Arneson Cc: Michael Shapiro , David.Kahn@sun.com, FWARC@sac.sfbay.sun.com Subject: Re: Error Notification Package [FWARC/2007/693 FastTrack timeout 12/21/2008] Message-ID: <20080103180945.GB251484@sun.com> References: <200801030805.m0385mD4246290@zion.sfbay.sun.com> <477D1E19.90306@Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <477D1E19.90306@Sun.COM> User-Agent: Mutt/1.4.2.1i Status: RO Content-Length: 1295 On Thu, Jan 03, 2008 at 12:40:41PM -0500, David Arneson wrote: > Mike, > > I do not think this will have any impact on FMA for OPL. The way this is > used it provides a way to report errors that are detected during PCI > probing inside OBP. Previously if an error occurred early in the OBP > probe cycle OBP would be unable to determine the correct device that > caused the problem. It would therefore degrade the parent, remove it > from the system. This may take out a number of good devices including > boot disk etc. > > Using the error notification package OBP now has a way to report errors > that occur early during the PCI probe and therefore degrade the correct > offending device. This also makes the OBP PCI probe code more error > tolerant. A useful note for the ARC opinion would be that if David's proposed standard package name is the way we expect OBP error probing to be done, then any future FMA work to cause OBP probing to be connected to FMA should leverage or build upon this interface. i.e. we should be slowly trying to converge on a standard set of OBP error interfaces that would permit better transfer of data from an OBP-detected failureu to an FMA implementation on the platform. -Mike -- Mike Shapiro, Solaris Kernel Development. blogs.sun.com/mws/