From sacadmin Wed Feb 11 12:41:59 2009 Received: from tethys.sfbay.sun.com (tethys.SFBay.Sun.COM [129.146.226.92]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n1BKfxcI013078; Wed, 11 Feb 2009 12:41:59 -0800 (PST) Received: from tethys.sfbay.sun.com (localhost [127.0.0.1]) by tethys.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id n1BKaVIk010088; Wed, 11 Feb 2009 12:36:31 -0800 (PST) Received: (from jg@localhost) by tethys.sfbay.sun.com (8.14.3+Sun/8.14.3/Submit) id n1BKaV2f010085; Wed, 11 Feb 2009 12:36:31 -0800 (PST) Date: Wed, 11 Feb 2009 12:36:31 -0800 (PST) From: Jerry Gilliam Message-Id: <200902112036.n1BKaV2f010085@tethys.sfbay.sun.com> To: PSARC-record@sac.sfbay.sun.com Subject: Reboot to firmware [PSARC/2009/091 FastTrack timeout 02/18/2009] Status: RO Content-Length: 549 Template Version: @(#)sac_nextcase %I% %G% SMI This information is Copyright 2009 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: Reboot to firmware 1.2. Name of Document Author/Supplier: Author: Sherry Moore 1.3 Date of This Document: 11 February, 2009 4. Technical Description See the case directory for more detail 6. Resources and Schedule 6.4. Steering Committee requested information 6.4.1. Consolidation C-team Name: ON 6.5. ARC review type: FastTrack 6.6. ARC Exposure: open From jg@jurassic.sfbay.Sun.COM Wed Feb 11 12:43:37 2009 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n1BKhbqf013214 for ; Wed, 11 Feb 2009 12:43:37 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n1BKhabJ020018; Wed, 11 Feb 2009 12:43:37 -0800 (PST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KEX00L0T5KOLF00@nwk-avmta-2.sfbay.sun.com>; Wed, 11 Feb 2009 12:43:36 -0800 (PST) Received: from jurassic.eng.sun.com ([129.146.228.50]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KEX00H6Z5KNIX80@nwk-avmta-2.sfbay.sun.com>; Wed, 11 Feb 2009 12:43:35 -0800 (PST) Received: from tethys (tethys.SFBay.Sun.COM [129.146.226.92]) by jurassic.eng.sun.com (8.13.8+Sun/8.13.8) with SMTP id n1BKhWGF527237; Wed, 11 Feb 2009 12:43:32 -0800 (PST) Date: Wed, 11 Feb 2009 12:38:04 -0800 (PST) From: Jerry Gilliam Subject: Reboot to firmware [PSARC/2009/091 02/18/2009] To: PSARC-ext@sun.com Cc: Sherry.Moore@sun.com Reply-to: Jerry Gilliam Message-id: <200902112043.n1BKhWGF527237@jurassic.eng.sun.com> MIME-version: 1.0 X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.7_98 SunOS 5.11 sun4u sparc Content-type: TEXT/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-MD5: 3CiAEIydj8voqiH/C3q1Hg== X-PMX-Version: 5.4.1.325704 Status: RO Content-Length: 2076 I am submitting the following fast-track on behalf of Sherry Moore. Minor release binding is requested. The timeout is set for 02-18-2009. -jg 1. Introduction 1.1. Project/Component Working Name: Adding -p option to reboot(1M). 1.2. Name of Document Author/Supplier: Sherry.Moore@sun.com 1.3. Date of This Document: 02/06/2009 1.3.1. Date this project was conceived: 10/01/2008 2. Project Summary 2.1. Project Description: This project will add the "-p" option to reboot(1M) to reboot through firmware. 4. Technical Description: 4.1. Details: With the introduction of 2008/760 Boot configuration Service reboot(1M) will behave as "reboot -f", which will bypass the firmware. Under some circumstances, such as when performing net installation, changing BIOS settings, or clearing some hardware states on the system, users might want the system to go through firmware. While one can easily disable the "Fast Reboot by default" feature by setting the "config/fastreboot_default" property in "system/boot-config" service to "false", it's preferable to have an option to reboot(1M) to achieve the same outcome without changing the default behavior. 4.2. Bug/RFE Number(s): TBD. 4.5. Interfaces: Minor binding only. 4.6. Doc Impact: Man pages for reboot(1M) needs to be modified. 4.6.1 Man pages for reboot(1M) -p | Reboot to prom. This flag can be used to reboot the | system through firmware without changing the default | reboot behavior as denoted by the | "config/fastreboot_default" property setting in | "system/boot-config" service. | | This option is currently available only on x86 systems. | 4.7. Admin/Config Impact The System Administration Guide needs to be updated to reflect the new option. 6. Resources and Schedule: 6.4. Steering Committee requested information 6.4.1. Consolidation C-team Name: ON 6.5. ARC review type: FastTrack 6.6. ARC Exposure: open From gdamore@sun.com Wed Feb 11 13:52:16 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n1BLqFgv017595 for ; Wed, 11 Feb 2009 13:52:15 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n1BLqFZr053986 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 11 Feb 2009 14:52:15 -0700 (MST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KEX002038R3FT00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 11 Feb 2009 13:52:15 -0800 (PST) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KEX00HN38R2J6D0@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 11 Feb 2009 13:52:14 -0800 (PST) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n1BLqELB012276 for ; Wed, 11 Feb 2009 13:52:14 -0800 (PST) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 23 2008)) id <0KEX00M008PQJA00@fe-sfbay-09.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 11 Feb 2009 13:52:14 -0800 (PST) Received: from [192.168.251.11] ([unknown] [76.93.15.33]) by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 23 2008)) with ESMTPSA id <0KEX00HN58QT6J80@fe-sfbay-09.sun.com>; Wed, 11 Feb 2009 13:52:10 -0800 (PST) Date: Wed, 11 Feb 2009 13:52:04 -0800 From: "Garrett D'Amore" Subject: Re: Reboot to firmware [PSARC/2009/091 02/18/2009] In-reply-to: <200902112043.n1BKhWGF527237@jurassic.eng.sun.com> Sender: Garrett.Damore@sun.com To: Jerry Gilliam Cc: PSARC-ext@sun.com, Sherry.Moore@sun.com Message-id: <49934884.6020505@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200902112043.n1BKhWGF527237@jurassic.eng.sun.com> User-Agent: Thunderbird 2.0.0.18 (X11/20081201) Status: RO Content-Length: 2261 +1 -- Garrett Jerry Gilliam wrote: > I am submitting the following fast-track on behalf of Sherry Moore. Minor > release binding is requested. The timeout is set for 02-18-2009. > > -jg > > > > 1. Introduction > 1.1. Project/Component Working Name: > Adding -p option to reboot(1M). > > 1.2. Name of Document Author/Supplier: > Sherry.Moore@sun.com > > 1.3. Date of This Document: > 02/06/2009 > > 1.3.1. Date this project was conceived: > 10/01/2008 > > 2. Project Summary > > 2.1. Project Description: > > This project will add the "-p" option to reboot(1M) to reboot > through firmware. > > 4. Technical Description: > > 4.1. Details: > > With the introduction of > > 2008/760 Boot configuration Service > > reboot(1M) will behave as "reboot -f", which will bypass the > firmware. Under some circumstances, such as when performing > net installation, changing BIOS settings, or clearing some > hardware states on the system, users might want the system to > go through firmware. While one can easily disable the "Fast > Reboot by default" feature by setting the > "config/fastreboot_default" property in "system/boot-config" > service to "false", it's preferable to have an option to > reboot(1M) to achieve the same outcome without changing the > default behavior. > > > 4.2. Bug/RFE Number(s): > > TBD. > > 4.5. Interfaces: > > Minor binding only. > > 4.6. Doc Impact: > > Man pages for reboot(1M) needs to be modified. > > 4.6.1 Man pages for reboot(1M) > > > -p | > Reboot to prom. This flag can be used to reboot the | > system through firmware without changing the default | > reboot behavior as denoted by the | > "config/fastreboot_default" property setting in | > "system/boot-config" service. | > | > This option is currently available only on x86 systems. | > > 4.7. Admin/Config Impact > > The System Administration Guide needs to be updated to reflect > the new option. > > 6. Resources and Schedule: > 6.4. Steering Committee requested information > 6.4.1. Consolidation C-team Name: > ON > 6.5. ARC review type: FastTrack > 6.6. ARC Exposure: open > > From Dana.Myers@sun.com Wed Feb 11 15:46:12 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n1BNkBIt022565 for ; Wed, 11 Feb 2009 15:46:12 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n1BNk6Ep056491 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 11 Feb 2009 16:46:11 -0700 (MST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KEX0081TE0XPT00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 11 Feb 2009 15:46:09 -0800 (PST) Received: from brmea-mail-1.sun.com ([192.18.98.31]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KEX004GME0W3130@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 11 Feb 2009 15:46:08 -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 n1BNk8R9010192 for ; Wed, 11 Feb 2009 23:46:08 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 23 2008)) id <0KEX00M00D174M00@mail-amer.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 11 Feb 2009 16:46:08 -0700 (MST) Received: from [192.168.0.100] (c-71-198-48-32.hsd1.ca.comcast.net [71.198.48.32]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 23 2008)) with ESMTPSA id <0KEX003QWE0FC060@mail-amer.sun.com>; Wed, 11 Feb 2009 16:45:52 -0700 (MST) Date: Wed, 11 Feb 2009 15:45:21 -0800 From: "Dana H. Myers" Subject: Re: Reboot to firmware [PSARC/2009/091 02/18/2009] In-reply-to: <200902112043.n1BKhWGF527237@jurassic.eng.sun.com> Sender: Dana.Myers@sun.com To: Jerry Gilliam Cc: PSARC-ext@sun.com, sherry.moore@sun.com Message-id: <49936311.6040301@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200902112043.n1BKhWGF527237@jurassic.eng.sun.com> User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) Status: RO Content-Length: 2893 Jerry Gilliam wrote: > I am submitting the following fast-track on behalf of Sherry Moore. Minor > release binding is requested. The timeout is set for 02-18-2009. > > As much as I appreciate the convenience of fast reboot, fast reboot is not mature enough to be made the default behavior. See CR 6760313, for the tip of the iceberg. Architecturally, we're cornered in that we're dependent on cooperative ACPI BIOS behavior. If we un-init and re-init the ACPI namespace, we'll run _INI methods more than once on a system that, from the BIOS perspective, hasn't been rebooted. I don't have a satisfactory general answer for this. I believe this case certainly warrants a full discussion. Dana > -jg > > > > 1. Introduction > 1.1. Project/Component Working Name: > Adding -p option to reboot(1M). > > 1.2. Name of Document Author/Supplier: > Sherry.Moore@sun.com > > 1.3. Date of This Document: > 02/06/2009 > > 1.3.1. Date this project was conceived: > 10/01/2008 > > 2. Project Summary > > 2.1. Project Description: > > This project will add the "-p" option to reboot(1M) to reboot > through firmware. > > 4. Technical Description: > > 4.1. Details: > > With the introduction of > > 2008/760 Boot configuration Service > > reboot(1M) will behave as "reboot -f", which will bypass the > firmware. Under some circumstances, such as when performing > net installation, changing BIOS settings, or clearing some > hardware states on the system, users might want the system to > go through firmware. While one can easily disable the "Fast > Reboot by default" feature by setting the > "config/fastreboot_default" property in "system/boot-config" > service to "false", it's preferable to have an option to > reboot(1M) to achieve the same outcome without changing the > default behavior. > > > 4.2. Bug/RFE Number(s): > > TBD. > > 4.5. Interfaces: > > Minor binding only. > > 4.6. Doc Impact: > > Man pages for reboot(1M) needs to be modified. > > 4.6.1 Man pages for reboot(1M) > > > -p | > Reboot to prom. This flag can be used to reboot the | > system through firmware without changing the default | > reboot behavior as denoted by the | > "config/fastreboot_default" property setting in | > "system/boot-config" service. | > | > This option is currently available only on x86 systems. | > > 4.7. Admin/Config Impact > > The System Administration Guide needs to be updated to reflect > the new option. > > 6. Resources and Schedule: > 6.4. Steering Committee requested information > 6.4.1. Consolidation C-team Name: > ON > 6.5. ARC review type: FastTrack > 6.6. ARC Exposure: open > > _______________________________________________ > opensolaris-arc mailing list > opensolaris-arc@opensolaris.org > > From gdamore@sun.com Wed Feb 11 16:10:11 2009 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n1C0ABCk021191 for ; Wed, 11 Feb 2009 16:10:11 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n1C0A8CR028283 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 11 Feb 2009 16:10:10 -0800 (PST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KEX00A0LF4XGF00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 11 Feb 2009 16:10:09 -0800 (PST) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KEX003Y5F4VQM60@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 11 Feb 2009 16:10:07 -0800 (PST) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n1C0A7BY020244 for ; Wed, 11 Feb 2009 16:10:07 -0800 (PST) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 23 2008)) id <0KEX00400EJO3C00@fe-sfbay-09.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 11 Feb 2009 16:10:07 -0800 (PST) Received: from [192.168.251.11] ([unknown] [76.93.15.33]) by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 23 2008)) with ESMTPSA id <0KEX00C57F4HPUF0@fe-sfbay-09.sun.com>; Wed, 11 Feb 2009 16:09:54 -0800 (PST) Date: Wed, 11 Feb 2009 16:09:53 -0800 From: "Garrett D'Amore" Subject: Re: Reboot to firmware [PSARC/2009/091 02/18/2009] In-reply-to: <49936311.6040301@sun.com> Sender: Garrett.Damore@sun.com To: "Dana H. Myers" Cc: Jerry Gilliam , PSARC-ext@sun.com, Sherry.Moore@sun.com Message-id: <499368D1.20705@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200902112043.n1BKhWGF527237@jurassic.eng.sun.com> <49936311.6040301@sun.com> User-Agent: Thunderbird 2.0.0.18 (X11/20081201) Status: RO Content-Length: 3624 Dana H. Myers wrote: > Jerry Gilliam wrote: >> I am submitting the following fast-track on behalf of Sherry Moore. >> Minor >> release binding is requested. The timeout is set for 02-18-2009. >> >> > As much as I appreciate the convenience of fast reboot, > fast reboot is not mature enough to be made the default behavior. > See CR 6760313, for the tip of the iceberg. Architecturally, we're > cornered in that we're dependent on cooperative ACPI BIOS > behavior. If we un-init and re-init the ACPI namespace, we'll > run _INI methods more than once on a system that, from the > BIOS perspective, hasn't been rebooted. I don't have a satisfactory > general answer for this. > > I believe this case certainly warrants a full discussion. I do not believe that this case (or any other) has changed the default. All this case does is is make an override option available to administrators that have manually changed the default. As such, I don't think a full discussion *on this case* is warranted. If a case were brought forward intended to change the default behavior, I would agree that a full discussion would be warranted. -- Garrett > > Dana > >> -jg >> >> >> >> 1. Introduction >> 1.1. Project/Component Working Name: >> Adding -p option to reboot(1M). >> >> 1.2. Name of Document Author/Supplier: >> Sherry.Moore@sun.com >> >> 1.3. Date of This Document: >> 02/06/2009 >> >> 1.3.1. Date this project was conceived: >> 10/01/2008 >> >> 2. Project Summary >> >> 2.1. Project Description: >> >> This project will add the "-p" option to reboot(1M) to reboot >> through firmware. >> >> 4. Technical Description: >> >> 4.1. Details: >> >> With the introduction of >> >> 2008/760 Boot configuration Service >> >> reboot(1M) will behave as "reboot -f", which will bypass the >> firmware. Under some circumstances, such as when performing >> net installation, changing BIOS settings, or clearing some >> hardware states on the system, users might want the system to >> go through firmware. While one can easily disable the "Fast >> Reboot by default" feature by setting the >> "config/fastreboot_default" property in "system/boot-config" >> service to "false", it's preferable to have an option to >> reboot(1M) to achieve the same outcome without changing the >> default behavior. >> >> >> 4.2. Bug/RFE Number(s): >> >> TBD. >> 4.5. Interfaces: >> >> Minor binding only. >> >> 4.6. Doc Impact: >> >> Man pages for reboot(1M) needs to be modified. >> >> 4.6.1 Man pages for reboot(1M) >> >> -p | >> Reboot to prom. This flag can be used to reboot the | >> system through firmware without changing the default | >> reboot behavior as denoted by the | >> "config/fastreboot_default" property setting in | >> "system/boot-config" service. | >> | >> This option is currently available only on x86 systems. | >> >> 4.7. Admin/Config Impact >> >> The System Administration Guide needs to be updated to reflect >> the new option. >> >> 6. Resources and Schedule: >> 6.4. Steering Committee requested information >> 6.4.1. Consolidation C-team Name: >> ON >> 6.5. ARC review type: FastTrack >> 6.6. ARC Exposure: open >> >> _______________________________________________ >> opensolaris-arc mailing list >> opensolaris-arc@opensolaris.org >> >> > From Dana.Myers@Sun.COM Wed Feb 11 16:24:23 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n1C0OM4E019327 for ; Wed, 11 Feb 2009 16:24:23 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n1C0OLhO003176 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 12 Feb 2009 00:24:21 GMT Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KEX00B0BFSHAQ00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 11 Feb 2009 16:24:17 -0800 (PST) Received: from brmea-mail-1.sun.com ([192.18.98.31]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KEX003L5FSGQG70@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 11 Feb 2009 16:24:17 -0800 (PST) Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n1C0OGwA025115 for ; Thu, 12 Feb 2009 00:24:16 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 23 2008)) id <0KEX00K00F9NLU00@mail-amer.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 11 Feb 2009 17:24:16 -0700 (MST) Received: from [192.168.0.100] (c-71-198-48-32.hsd1.ca.comcast.net [71.198.48.32]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 23 2008)) with ESMTPSA id <0KEX000DQFRHB180@mail-amer.sun.com>; Wed, 11 Feb 2009 17:23:42 -0700 (MST) Date: Wed, 11 Feb 2009 16:23:11 -0800 From: "Dana H. Myers" Subject: Re: Reboot to firmware [PSARC/2009/091 02/18/2009] In-reply-to: <499368D1.20705@sun.com> Sender: Dana.Myers@Sun.COM To: "Garrett D'Amore" Cc: Jerry Gilliam , PSARC-ext@Sun.COM, Sherry.Moore@Sun.COM Message-id: <49936BEF.4000501@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200902112043.n1BKhWGF527237@jurassic.eng.sun.com> <49936311.6040301@sun.com> <499368D1.20705@sun.com> User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) Status: RO Content-Length: 1659 Garrett D'Amore wrote: > Dana H. Myers wrote: >> Jerry Gilliam wrote: >>> I am submitting the following fast-track on behalf of Sherry Moore. >>> Minor >>> release binding is requested. The timeout is set for 02-18-2009. >>> >>> >> As much as I appreciate the convenience of fast reboot, >> fast reboot is not mature enough to be made the default behavior. >> See CR 6760313, for the tip of the iceberg. Architecturally, we're >> cornered in that we're dependent on cooperative ACPI BIOS >> behavior. If we un-init and re-init the ACPI namespace, we'll >> run _INI methods more than once on a system that, from the >> BIOS perspective, hasn't been rebooted. I don't have a satisfactory >> general answer for this. >> >> I believe this case certainly warrants a full discussion. > > I do not believe that this case (or any other) has changed the > default. All this case does is is make an override option available > to administrators that have manually changed the default. > > As such, I don't think a full discussion *on this case* is warranted. > > If a case were brought forward intended to change the default > behavior, I would agree that a full discussion would be warranted. > So, I went back and looked at 2008/760, which does indeed provide the ability to set the default behavior of 'reboot', though the following sentence in *this* case: >>> >>> >>> With the introduction of >>> >>> 2008/760 Boot configuration Service >>> >>> reboot(1M) will behave as "reboot -f", which will bypass the >>> firmware. ... was disturbing. Is the "stock" default behavior of 'reboot' a PROM reboot? Or is it fast reboot? Dana From gdamore@Sun.COM Wed Feb 11 16:44:49 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n1C0ilLF020404 for ; Wed, 11 Feb 2009 16:44:48 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n1C0ijAt015294 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 12 Feb 2009 00:44:47 GMT Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KEX00909GQL2E00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 11 Feb 2009 17:44:45 -0700 (MST) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KEX00EZAGQKXDE0@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 11 Feb 2009 17:44:44 -0700 (MST) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n1C0iieJ000131 for ; Wed, 11 Feb 2009 16:44:44 -0800 (PST) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 23 2008)) id <0KEX00E00GGCD300@fe-sfbay-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 11 Feb 2009 16:44:44 -0800 (PST) Received: from [192.168.251.11] ([unknown] [76.93.15.33]) by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 23 2008)) with ESMTPSA id <0KEX004G4GQIIU50@fe-sfbay-10.sun.com>; Wed, 11 Feb 2009 16:44:42 -0800 (PST) Date: Wed, 11 Feb 2009 16:44:42 -0800 From: "Garrett D'Amore" Subject: Re: Reboot to firmware [PSARC/2009/091 02/18/2009] In-reply-to: <49936BEF.4000501@sun.com> Sender: Garrett.Damore@Sun.COM To: "Dana H. Myers" Cc: Jerry Gilliam , PSARC-ext@Sun.COM, Sherry.Moore@Sun.COM Message-id: <499370FA.1070102@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200902112043.n1BKhWGF527237@jurassic.eng.sun.com> <49936311.6040301@sun.com> <499368D1.20705@sun.com> <49936BEF.4000501@sun.com> User-Agent: Thunderbird 2.0.0.18 (X11/20081201) Status: RO Content-Length: 2254 Hmm... 2008/760 *does* say its enabled by default. That got approved as a fast track. Sounds like there are some issues here. However, are the problems with this "architectural" in scope, or are they more "bugs" in scope? (I.e. if we got the bugs resolved properly, is there any good reason why the approval of 2008/760 shouldn't have been granted?) My gut here says the problems are just bugs (maybe severe ones!), and not a problem with system architecture as a whole. Do I misunderstand? -- Garrett Dana H. Myers wrote: > Garrett D'Amore wrote: >> Dana H. Myers wrote: >>> Jerry Gilliam wrote: >>>> I am submitting the following fast-track on behalf of Sherry >>>> Moore. Minor >>>> release binding is requested. The timeout is set for 02-18-2009. >>>> >>>> >>> As much as I appreciate the convenience of fast reboot, >>> fast reboot is not mature enough to be made the default behavior. >>> See CR 6760313, for the tip of the iceberg. Architecturally, we're >>> cornered in that we're dependent on cooperative ACPI BIOS >>> behavior. If we un-init and re-init the ACPI namespace, we'll >>> run _INI methods more than once on a system that, from the >>> BIOS perspective, hasn't been rebooted. I don't have a satisfactory >>> general answer for this. >>> >>> I believe this case certainly warrants a full discussion. >> >> I do not believe that this case (or any other) has changed the >> default. All this case does is is make an override option available >> to administrators that have manually changed the default. >> >> As such, I don't think a full discussion *on this case* is warranted. >> >> If a case were brought forward intended to change the default >> behavior, I would agree that a full discussion would be warranted. >> > So, I went back and looked at 2008/760, which does indeed > provide the ability to set the default behavior of 'reboot', though the > following sentence in *this* case: > >>>> >>>> >>>> With the introduction of >>>> >>>> 2008/760 Boot configuration Service >>>> >>>> reboot(1M) will behave as "reboot -f", which will bypass the >>>> firmware. > > ... was disturbing. Is the "stock" default behavior of 'reboot' a > PROM reboot? Or is it fast reboot? > > Dana > From Dana.Myers@Sun.COM Wed Feb 11 16:50:55 2009 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n1C0otbr020560 for ; Wed, 11 Feb 2009 16:50:55 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n1C0oqxp028877 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 11 Feb 2009 16:50:55 -0800 (PST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KEX00907H0UQI00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 11 Feb 2009 17:50:54 -0700 (MST) Received: from brmea-mail-1.sun.com ([192.18.98.31]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KEX00EBMH0UXLE0@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 11 Feb 2009 17:50:54 -0700 (MST) 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 n1C0os61004602 for ; Thu, 12 Feb 2009 00:50:54 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 23 2008)) id <0KEX00M00GY6BP00@mail-amer.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 11 Feb 2009 17:50:54 -0700 (MST) Received: from [192.168.0.100] (c-71-198-48-32.hsd1.ca.comcast.net [71.198.48.32]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 23 2008)) with ESMTPSA id <0KEX003Y5H0TC080@mail-amer.sun.com>; Wed, 11 Feb 2009 17:50:54 -0700 (MST) Date: Wed, 11 Feb 2009 16:50:23 -0800 From: "Dana H. Myers" Subject: Re: Reboot to firmware [PSARC/2009/091 02/18/2009] In-reply-to: <499370FA.1070102@sun.com> Sender: Dana.Myers@Sun.COM To: "Garrett D'Amore" Cc: Jerry Gilliam , PSARC-ext@Sun.COM, Sherry.Moore@Sun.COM Message-id: <4993724F.50805@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200902112043.n1BKhWGF527237@jurassic.eng.sun.com> <49936311.6040301@sun.com> <499368D1.20705@sun.com> <49936BEF.4000501@sun.com> <499370FA.1070102@sun.com> User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) Status: RO Content-Length: 2665 Garrett D'Amore wrote: > Hmm... 2008/760 *does* say its enabled by default. That got approved > as a fast track. Sounds like there are some issues here. That was right before the holidays, I must not have been watching. > > However, are the problems with this "architectural" in scope, or are > they more "bugs" in scope? (I.e. if we got the bugs resolved > properly, is there any good reason why the approval of 2008/760 > shouldn't have been granted?) > > My gut here says the problems are just bugs (maybe severe ones!), and > not a problem with system architecture as a whole. Do I misunderstand? What's "just a bug"? Something not working as designed, right? Applying this standard, my comments stand - there's an architectural disconnect. At the *very least*, this class of issue should have been included in the 2008/760 one-pager. Dana > > -- Garrett > > Dana H. Myers wrote: >> Garrett D'Amore wrote: >>> Dana H. Myers wrote: >>>> Jerry Gilliam wrote: >>>>> I am submitting the following fast-track on behalf of Sherry >>>>> Moore. Minor >>>>> release binding is requested. The timeout is set for 02-18-2009. >>>>> >>>>> >>>> As much as I appreciate the convenience of fast reboot, >>>> fast reboot is not mature enough to be made the default behavior. >>>> See CR 6760313, for the tip of the iceberg. Architecturally, we're >>>> cornered in that we're dependent on cooperative ACPI BIOS >>>> behavior. If we un-init and re-init the ACPI namespace, we'll >>>> run _INI methods more than once on a system that, from the >>>> BIOS perspective, hasn't been rebooted. I don't have a satisfactory >>>> general answer for this. >>>> >>>> I believe this case certainly warrants a full discussion. >>> >>> I do not believe that this case (or any other) has changed the >>> default. All this case does is is make an override option available >>> to administrators that have manually changed the default. >>> >>> As such, I don't think a full discussion *on this case* is warranted. >>> >>> If a case were brought forward intended to change the default >>> behavior, I would agree that a full discussion would be warranted. >>> >> So, I went back and looked at 2008/760, which does indeed >> provide the ability to set the default behavior of 'reboot', though the >> following sentence in *this* case: >> >>>>> >>>>> >>>>> With the introduction of >>>>> >>>>> 2008/760 Boot configuration Service >>>>> >>>>> reboot(1M) will behave as "reboot -f", which will bypass the >>>>> firmware. >> >> ... was disturbing. Is the "stock" default behavior of 'reboot' a >> PROM reboot? Or is it fast reboot? >> >> Dana >> > > From sherry.moore@sun.com Wed Feb 11 17:00:28 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n1C10S4O022915 for ; Wed, 11 Feb 2009 17:00:28 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n1C10OwL024146; Wed, 11 Feb 2009 18:00:26 -0700 (MST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KEX00A0DHGPNX00@brm-avmta-1.central.sun.com>; Wed, 11 Feb 2009 18:00:25 -0700 (MST) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.63]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KEX00E9EHGOXLF0@brm-avmta-1.central.sun.com>; Wed, 11 Feb 2009 18:00:24 -0700 (MST) Received: from jurassic-x4600.sfbay.sun.com (localhost [127.0.0.1]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id n1C10KW7582860 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 11 Feb 2009 17:00:20 -0800 (PST) Received: (from sherrym@localhost) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3/Submit) id n1C10KsK582857; Wed, 11 Feb 2009 17:00:20 -0800 (PST) Date: Wed, 11 Feb 2009 17:00:20 -0800 From: Sherry Moore Subject: Re: Reboot to firmware [PSARC/2009/091 02/18/2009] In-reply-to: <49936BEF.4000501@sun.com> To: "Dana H. Myers" Cc: "Garrett D'Amore" , Jerry Gilliam , PSARC-ext@sun.com, sherry.moore@sun.com Message-id: <20090212010020.GA559215@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <200902112043.n1BKhWGF527237@jurassic.eng.sun.com> <49936311.6040301@sun.com> <499368D1.20705@sun.com> <49936BEF.4000501@sun.com> X-Authentication-warning: jurassic-x4600.sfbay.sun.com: sherrym set sender to sherry.moore@sun.com using -f User-Agent: Mutt/1.5.17 (2007-11-01) Status: RO Content-Length: 1227 Hi Dana, >>>> With the introduction of >>>> >>>> 2008/760 Boot configuration Service >>>> >>>> reboot(1M) will behave as "reboot -f", which will bypass the >>>> firmware. > > ... was disturbing. Is the "stock" default behavior of 'reboot' a > PROM reboot? Or is it fast reboot? The code changes for 2008/760 Boot configuration Service has not been integrated yet. They will be put back along with the changes for this case. This case will not only address usage models such as net boot, changing BIOS settings, resetting hardware, but will also provide an option to fall back to the old behavior in case a system is incapable of dealing with Fast Reboot. Considering your concern, this case is exactly what the doctor orders. :) To address the particular issue in 6760313, we have implemented a blacklisting mechanism to disable the boot config service on systems we know are incapable Fast Reboot. But I would like to see an "architecture solution" to the bug with appropriate priority rather than seeing it being from a "bug" to and "RFE". In any case, I will work with you offline and post a summary to PSARC. Thanks, Sherry -- Sherry Moore, Solaris Core Kernel http://blogs.sun.com/sherrym From Dana.Myers@Sun.COM Wed Feb 11 17:07:18 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n1C17HA0024611 for ; Wed, 11 Feb 2009 17:07:17 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n1C178Jc028646 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 12 Feb 2009 01:07:16 GMT Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KEX00B03HS3B100@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 11 Feb 2009 18:07:15 -0700 (MST) Received: from brmea-mail-1.sun.com ([192.18.98.31]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KEX00E4JHS3XIF0@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 11 Feb 2009 18:07:15 -0700 (MST) 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 n1C17FLn010579 for ; Thu, 12 Feb 2009 01:07:15 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 23 2008)) id <0KEX00000HQYVN00@mail-amer.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 11 Feb 2009 18:07:15 -0700 (MST) Received: from [192.168.0.100] (c-71-198-48-32.hsd1.ca.comcast.net [71.198.48.32]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 23 2008)) with ESMTPSA id <0KEX003CGHRXC090@mail-amer.sun.com>; Wed, 11 Feb 2009 18:07:10 -0700 (MST) Date: Wed, 11 Feb 2009 17:06:39 -0800 From: "Dana H. Myers" Subject: Re: Reboot to firmware [PSARC/2009/091 02/18/2009] In-reply-to: <20090212010020.GA559215@sun.com> Sender: Dana.Myers@Sun.COM To: Sherry Moore Cc: "Garrett D'Amore" , Jerry Gilliam , PSARC-ext@Sun.COM Message-id: <4993761F.8000104@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200902112043.n1BKhWGF527237@jurassic.eng.sun.com> <49936311.6040301@sun.com> <499368D1.20705@sun.com> <49936BEF.4000501@sun.com> <20090212010020.GA559215@sun.com> User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) Status: RO Content-Length: 1856 Sherry Moore wrote: > Hi Dana, > > >>>>> With the introduction of >>>>> >>>>> 2008/760 Boot configuration Service >>>>> >>>>> reboot(1M) will behave as "reboot -f", which will bypass the >>>>> firmware. >>>>> >> ... was disturbing. Is the "stock" default behavior of 'reboot' a >> PROM reboot? Or is it fast reboot? >> > > The code changes for > 2008/760 Boot configuration Service > has not been integrated yet. They will be put back along with the > changes for this case. This case will not only address usage models > such as net boot, changing BIOS settings, resetting hardware, but will > also provide an option to fall back to the old behavior in case a > system is incapable of dealing with Fast Reboot. Considering your > concern, this case is exactly what the doctor orders. :) > I'm more concerned about failures during an attempted fast reboot. I have no fundamental issue at all with 2008/760 and a sysadmin having the ability to set the default behavior to 'fast reboot' - as long as the out-of-box behavior is 'normal reboot' and the sysadmin first confirms they are happy with fast reboot behavior. > To address the particular issue in 6760313, we have implemented a > blacklisting mechanism to disable the boot config service on systems we > know are incapable Fast Reboot. But I would like to see an > "architecture solution" to the bug with appropriate priority rather > than seeing it being from a "bug" to and "RFE". > You're asking for an entirely new behavior from the ACPI CA subsystem. That's an RFE, and one with external-to-Sun implications. There's no issue with 2009/091, and 2008/760 would seem fine if the installed default is a normal reboot. > In any case, I will work with you offline and post a summary to PSARC. > > Sounds good - Dana > Thanks, > Sherry > From gdamore@sun.com Wed Feb 11 17:13:52 2009 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n1C1Dqlr025165 for ; Wed, 11 Feb 2009 17:13:52 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n1C1DoNi022321 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 11 Feb 2009 17:13:52 -0800 (PST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KEX00B07I33YV00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 11 Feb 2009 18:13:51 -0700 (MST) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KEX00EC8I33X9F0@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 11 Feb 2009 18:13:51 -0700 (MST) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n1C1Do0T002640 for ; Wed, 11 Feb 2009 17:13:50 -0800 (PST) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 23 2008)) id <0KEX00200HXGLG00@fe-sfbay-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 11 Feb 2009 17:13:50 -0800 (PST) Received: from [192.168.251.11] ([unknown] [76.93.15.33]) by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 23 2008)) with ESMTPSA id <0KEX004J5I327H00@fe-sfbay-10.sun.com>; Wed, 11 Feb 2009 17:13:50 -0800 (PST) Date: Wed, 11 Feb 2009 17:13:49 -0800 From: "Garrett D'Amore" Subject: Re: Reboot to firmware [PSARC/2009/091 02/18/2009] In-reply-to: <4993761F.8000104@sun.com> Sender: Garrett.Damore@sun.com To: "Dana H. Myers" Cc: Sherry Moore , Jerry Gilliam , PSARC-ext@sun.com Message-id: <499377CD.5090106@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200902112043.n1BKhWGF527237@jurassic.eng.sun.com> <49936311.6040301@sun.com> <499368D1.20705@sun.com> <49936BEF.4000501@sun.com> <20090212010020.GA559215@sun.com> <4993761F.8000104@sun.com> User-Agent: Thunderbird 2.0.0.18 (X11/20081201) Status: RO Content-Length: 2445 So, if I may be so bold as to make a suggestion: Can we please modify 2008/760 to make fast-reboot *not* enabled by default? A follow on case can be submitted to change the default behavior later, when everyone is comfortable with it. Sherry, if you agree with this course of action, then I'd recommend sending a note to the case log of 2008/760 indicating this. I don't think we need to reopen it or have further discussion about such a change, if you're agreeable to it. -- Garrett Dana H. Myers wrote: > Sherry Moore wrote: >> Hi Dana, >> >> >>>>>> With the introduction of >>>>>> >>>>>> 2008/760 Boot configuration Service >>>>>> >>>>>> reboot(1M) will behave as "reboot -f", which will bypass the >>>>>> firmware. >>>>>> >>> ... was disturbing. Is the "stock" default behavior of 'reboot' a >>> PROM reboot? Or is it fast reboot? >>> >> >> The code changes for >> 2008/760 Boot configuration Service has not been integrated yet. >> They will be put back along with the >> changes for this case. This case will not only address usage models >> such as net boot, changing BIOS settings, resetting hardware, but will >> also provide an option to fall back to the old behavior in case a >> system is incapable of dealing with Fast Reboot. Considering your >> concern, this case is exactly what the doctor orders. :) >> > I'm more concerned about failures during an attempted fast reboot. > I have no fundamental issue at all with 2008/760 and a sysadmin > having the ability to set the default behavior to 'fast reboot' - as long > as the out-of-box behavior is 'normal reboot' and the sysadmin first > confirms they are happy with fast reboot behavior. >> To address the particular issue in 6760313, we have implemented a >> blacklisting mechanism to disable the boot config service on systems we >> know are incapable Fast Reboot. But I would like to see an >> "architecture solution" to the bug with appropriate priority rather >> than seeing it being from a "bug" to and "RFE". >> > You're asking for an entirely new behavior from the ACPI CA > subsystem. That's an RFE, > and one with external-to-Sun implications. > > There's no issue with 2009/091, and 2008/760 would seem fine if the > installed > default is a normal reboot. >> In any case, I will work with you offline and post a summary to PSARC. >> >> > Sounds good - > Dana > >> Thanks, >> Sherry >> > From gdamore@sun.com Wed Feb 11 17:16:52 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n1C1GpDA025300 for ; Wed, 11 Feb 2009 17:16:51 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n1C1Glxk004236 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 12 Feb 2009 01:16:50 GMT Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KEX00C03I81AD00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 11 Feb 2009 18:16:49 -0700 (MST) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KEX00E38I80XCF0@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 11 Feb 2009 18:16:48 -0700 (MST) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n1C1GmqQ002860 for ; Wed, 11 Feb 2009 17:16:48 -0800 (PST) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 23 2008)) id <0KEX00100I5CN500@fe-sfbay-09.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 11 Feb 2009 17:16:48 -0800 (PST) Received: from [192.168.251.11] ([unknown] [76.93.15.33]) by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 23 2008)) with ESMTPSA id <0KEX0062ZI7Z7070@fe-sfbay-09.sun.com>; Wed, 11 Feb 2009 17:16:47 -0800 (PST) Date: Wed, 11 Feb 2009 17:16:47 -0800 From: "Garrett D'Amore" Subject: Re: Reboot to firmware [PSARC/2009/091 02/18/2009] In-reply-to: <4993724F.50805@sun.com> Sender: Garrett.Damore@sun.com To: "Dana H. Myers" Cc: Jerry Gilliam , PSARC-ext@sun.com, Sherry.Moore@sun.com Message-id: <4993787F.1050206@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200902112043.n1BKhWGF527237@jurassic.eng.sun.com> <49936311.6040301@sun.com> <499368D1.20705@sun.com> <49936BEF.4000501@sun.com> <499370FA.1070102@sun.com> <4993724F.50805@sun.com> User-Agent: Thunderbird 2.0.0.18 (X11/20081201) Status: RO Content-Length: 3268 Dana H. Myers wrote: > Garrett D'Amore wrote: >> Hmm... 2008/760 *does* say its enabled by default. That got approved >> as a fast track. Sounds like there are some issues here. > That was right before the holidays, I must not have been watching. >> >> However, are the problems with this "architectural" in scope, or are >> they more "bugs" in scope? (I.e. if we got the bugs resolved >> properly, is there any good reason why the approval of 2008/760 >> shouldn't have been granted?) >> >> My gut here says the problems are just bugs (maybe severe ones!), and >> not a problem with system architecture as a whole. Do I misunderstand? > What's "just a bug"? Something not working as designed, right? Applying > this standard, my comments stand - there's an architectural disconnect. As a litmus test: If the "design" (at least that part of it to which PSARC has been exposed) is defective, then its an architectural problem. However, if the problems can be resolved without changing the interfaces that were ARC'd, then the problem is "Just a bug". Note that being a just a bug has nothing to do with complexity or severity; the issue here is how this piece fits in with the interfaces that were supplied to ARC. > > At the *very least*, this class of issue should have been included in the > 2008/760 one-pager. Possibly. Was this problem understood then? -- Garrett > > Dana > >> >> -- Garrett >> >> Dana H. Myers wrote: >>> Garrett D'Amore wrote: >>>> Dana H. Myers wrote: >>>>> Jerry Gilliam wrote: >>>>>> I am submitting the following fast-track on behalf of Sherry >>>>>> Moore. Minor >>>>>> release binding is requested. The timeout is set for 02-18-2009. >>>>>> >>>>>> >>>>> As much as I appreciate the convenience of fast reboot, >>>>> fast reboot is not mature enough to be made the default behavior. >>>>> See CR 6760313, for the tip of the iceberg. Architecturally, we're >>>>> cornered in that we're dependent on cooperative ACPI BIOS >>>>> behavior. If we un-init and re-init the ACPI namespace, we'll >>>>> run _INI methods more than once on a system that, from the >>>>> BIOS perspective, hasn't been rebooted. I don't have a satisfactory >>>>> general answer for this. >>>>> >>>>> I believe this case certainly warrants a full discussion. >>>> >>>> I do not believe that this case (or any other) has changed the >>>> default. All this case does is is make an override option >>>> available to administrators that have manually changed the default. >>>> >>>> As such, I don't think a full discussion *on this case* is warranted. >>>> >>>> If a case were brought forward intended to change the default >>>> behavior, I would agree that a full discussion would be warranted. >>>> >>> So, I went back and looked at 2008/760, which does indeed >>> provide the ability to set the default behavior of 'reboot', though the >>> following sentence in *this* case: >>> >>>>>> >>>>>> >>>>>> With the introduction of >>>>>> >>>>>> 2008/760 Boot configuration Service >>>>>> >>>>>> reboot(1M) will behave as "reboot -f", which will bypass the >>>>>> firmware. >>> >>> ... was disturbing. Is the "stock" default behavior of 'reboot' a >>> PROM reboot? Or is it fast reboot? >>> >>> Dana >>> >> >> > From Dana.Myers@sun.com Wed Feb 11 17:25:03 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n1C1P3cB025779 for ; Wed, 11 Feb 2009 17:25:03 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n1C1OqZn009579 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 12 Feb 2009 01:25:02 GMT Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KEX00M01ILO1K00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 11 Feb 2009 17:25:00 -0800 (PST) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KEX0041CILN34E0@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 11 Feb 2009 17:24:59 -0800 (PST) Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n1C1Ox1q023125 for ; Thu, 12 Feb 2009 01:24:59 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 23 2008)) id <0KEX00400ILK3600@mail-amer.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 11 Feb 2009 18:24:59 -0700 (MST) Received: from [192.168.0.100] (c-71-198-48-32.hsd1.ca.comcast.net [71.198.48.32]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 23 2008)) with ESMTPSA id <0KEX0001XILMB1A0@mail-amer.sun.com>; Wed, 11 Feb 2009 18:24:59 -0700 (MST) Date: Wed, 11 Feb 2009 17:24:28 -0800 From: "Dana H. Myers" Subject: Re: Reboot to firmware [PSARC/2009/091 02/18/2009] In-reply-to: <4993787F.1050206@sun.com> Sender: Dana.Myers@sun.com To: "Garrett D'Amore" Cc: Jerry Gilliam , PSARC-ext@sun.com, Sherry.Moore@sun.com Message-id: <49937A4C.1080204@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200902112043.n1BKhWGF527237@jurassic.eng.sun.com> <49936311.6040301@sun.com> <499368D1.20705@sun.com> <49936BEF.4000501@sun.com> <499370FA.1070102@sun.com> <4993724F.50805@sun.com> <4993787F.1050206@sun.com> User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) Status: RO Content-Length: 1443 Garrett D'Amore wrote: > Dana H. Myers wrote: >> What's "just a bug"? Something not working as designed, right? >> Applying >> this standard, my comments stand - there's an architectural disconnect. > As a litmus test: > > If the "design" (at least that part of it to which PSARC has been > exposed) is defective, then its an architectural problem. However, if > the problems can be resolved without changing the interfaces that were > ARC'd, then the problem is "Just a bug". > > Note that being a just a bug has nothing to do with complexity or > severity; the issue here is how this piece fits in with the interfaces > that were supplied to ARC. CR 6760313 reports the result of not quiescing the ACPI CA sub-system. Architecturally, there's no interface in the Solaris acpica sub-system to quiesce or "re-init" data structures that are out-of-sync with the platform state as part of a fast-reboot. However, the problem is potentially more difficult; even given such an interface, it's not clear that system BIOSes would universally be accustomed to the OS/ACPI subsystem stopping/restarting/re-initializing. It's not a use-case that appears to be common at all - it does not appear to be a Windows scenario, which is the test-case for BIOS developers :-) >> >> At the *very least*, this class of issue should have been included in >> the >> 2008/760 one-pager. > > Possibly. Was this problem understood then? Yes. Dana From Dana.Myers@sun.com Thu Feb 12 09:56:35 2009 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n1CHuZx1021879 for ; Thu, 12 Feb 2009 09:56:35 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n1CHuYkm022790 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 12 Feb 2009 09:56:35 -0800 (PST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KEY00I0NSI91Q00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 12 Feb 2009 10:56:33 -0700 (MST) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KEY005UNSI9GUB0@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 12 Feb 2009 10:56:33 -0700 (MST) Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n1CHuXRk015178 for ; Thu, 12 Feb 2009 17:56:33 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 23 2008)) id <0KEY00100S0K6X00@mail-amer.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 12 Feb 2009 10:56:33 -0700 (MST) Received: from [192.168.0.100] (c-71-198-48-32.hsd1.ca.comcast.net [71.198.48.32]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 23 2008)) with ESMTPSA id <0KEY00CT2SI5VP40@mail-amer.sun.com>; Thu, 12 Feb 2009 10:56:29 -0700 (MST) Date: Thu, 12 Feb 2009 09:55:55 -0800 From: "Dana H. Myers" Subject: Re: Reboot to firmware [PSARC/2009/091 02/18/2009] In-reply-to: <499377CD.5090106@sun.com> Sender: Dana.Myers@sun.com To: "Garrett D'Amore" Cc: Sherry Moore , Jerry Gilliam , PSARC-ext@sun.com Message-id: <499462AB.6030102@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200902112043.n1BKhWGF527237@jurassic.eng.sun.com> <49936311.6040301@sun.com> <499368D1.20705@sun.com> <49936BEF.4000501@sun.com> <20090212010020.GA559215@sun.com> <4993761F.8000104@sun.com> <499377CD.5090106@sun.com> User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) Status: RO Content-Length: 2735 Garrett D'Amore wrote: > So, if I may be so bold as to make a suggestion: > > Can we please modify 2008/760 to make fast-reboot *not* enabled by > default? A follow on case can be submitted to change the default > behavior later, when everyone is comfortable with it. > > Sherry, if you agree with this course of action, then I'd recommend > sending a note to the case log of 2008/760 indicating this. I don't > think we need to reopen it or have further discussion about such a > change, if you're agreeable to it. I suggest adding the following text to section 2.2 "Risk and Assumptions" of 2008/760 (without re-opening the case): As of today, architecturally, there's no interface in the Solaris acpica sub-system to quiesce or "re-init" data structures that are out-of-sync with the platform state as part of a fast-reboot. CR 6760313 reports a result of not quiescing the ACPI CA sub-system. However, the problem is potentially more difficult; even given such an interface, it's not clear that system BIOSes would universally be accustomed to the OS/ACPI subsystem stopping/restarting/re-initializing. Fortunately, the vast majority of BIOSes appear to be idempotent in this regard. However, BIOS may maintain "platform" state, with the inherent assumption that this state is initialized during boot-up. Without the BIOS being aware of a reboot, the "platform" state may not properly synchronize with the ACPI namespace when it is re-created. Of perhaps more importance - after a reset, a system starts in "Legacy" mode, which fundamentally means that platform-related events (power button is the most common example) are handled by the platform BIOS in SMM code. Starting-up ACPI, the system is switched to ACPI mode, which permits the OS to handle events (like the power button, and, on a very few systems for semi-obvious reasons, thermal/fan control). So, the OS could see interrupt requests earlier than expected, but we're relatively safe in that respect. Some (buggy) BIOSes might perturb the system hardware state as a result of the Legacy->ACPI mode switch in totally unexpected ways. It's unclear how that might manifest itself after a fast-reboot - where the Legacy->ACPI mode switch almost certainly doesn't occur - the platform had been in ACPI mode all along. In short, there are risks to turn Fast Reboot on by default that people should be aware. We do have several mechanism to disable Fast Reboot should unforeseen problems arise: a) Black-listing b) Disabling the boot-config service c) reboot -p This would resolve my concerns. Cheers, Dana From jg@jurassic.sfbay.Sun.COM Thu Feb 19 15:10:10 2009 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n1JNAAHF021334 for ; Thu, 19 Feb 2009 15:10:10 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n1JNA286008012; Thu, 19 Feb 2009 15:10:10 -0800 (PST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KFC0080P5OSYB00@nwk-avmta-2.sfbay.sun.com>; Thu, 19 Feb 2009 15:10:04 -0800 (PST) Received: from jurassic.eng.sun.com ([129.146.106.105]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KFC005O35OGS060@nwk-avmta-2.sfbay.sun.com>; Thu, 19 Feb 2009 15:09:52 -0800 (PST) Received: from tethys (tethys.SFBay.Sun.COM [129.146.226.92]) by jurassic.eng.sun.com (8.13.8+Sun/8.13.8) with SMTP id n1JN9fYW230631; Thu, 19 Feb 2009 15:09:41 -0800 (PST) Date: Thu, 19 Feb 2009 15:04:10 -0800 (PST) From: Jerry Gilliam Subject: Re: Reboot to firmware [PSARC/2009/091 FastTrack timeout 02/18/2009] To: PSARC-ext@sun.com, sherry.moore@sun.com Reply-to: Jerry Gilliam Message-id: <200902192309.n1JN9fYW230631@jurassic.eng.sun.com> MIME-version: 1.0 X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.7_98 SunOS 5.11 sun4u sparc Content-type: TEXT/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-MD5: pOyTpKbCeFgeeD4j9twolw== X-PMX-Version: 5.4.1.325704 Status: RO Content-Length: 86 This fast-track has expired so I am now marking this case as closed approved. -jg