tomer/system admin friendly to state something
> >like "Fast reboot not supported on this machine" rather
> >than above message which assumes some knowledge
> >of device drivers and driver entry points.
> >
> >Margot
> >
> >
> >Garrett D&#
t; >>> Lovely. Is that documented anywhere? I don't see it in the
> >>>man page for
> >>> reboot(1M). Seems like an ideal extension to the text you
> >>>proposed along the
> >>> lines of "To see if your system is capable of fast reboot
> > > reboot -f dryrun shows whether your system is capable at all.
> >
> > Lovely. Is that documented anywhere? I don't see it in the man page for
> > reboot(1M). Seems like an ideal extension to the text you proposed along
> > the
> > lines of "To see if your system is capable of fast rebo
enu is: /rpool/boot/grub/menu.lst
> default 0
> timeout 10
> 0 zfsbe1
> 1 zfsbe1 failsafe
> 2 zfsbe2
> 3 zfsbe2 Solaris xVM
> 4 zfsbe2 failsafe
> example# reboot 2
>
>
>
> FILES
> /
The project team would like the latest man page reflected in the case
archive. man-page.txt and man-page-diff.txt can be found in the
materials directory.
They have also been attached for easy viewing.
Sherry
--
Sherry Moore, Solaris Core Kernel http://blogs.sun.com/sherrym
the interest list.
Sherry
--
Sherry Moore, Solaris Core Kernel http://blogs.sun.com/sherrym
> My suggestion was that before we move forward, it would be best for
> someone knowledgable of the requirements to first start a discussion
> with the external ConsoleKit community to determine the best way to
> integrate this feature.
I would like this as well. I am however not that person. If
we have sufficient information to send mail to these
aliases, by all means, and please let me know what they suggest.
Sherry
--
Sherry Moore, Solaris Core Kernel http://blogs.sun.com/sherrym
aliases (GDM and ConsoleKit) to seek
approval if such approval is deemed necessary.
(d) come back to LSARC with the spec and continue
Please let me know if this sounds OK.
Thanks,
Sherry
--
Sherry Moore, Solaris Core Kernel http://blogs.sun.com/sherrym
.
====
Date: Wed, 05 Aug 2009 14:45:10 -0700
From sherry.moore at sun.com Wed Aug 5 14:42:11 2009
From: Sherry Moore
To: Brian Cameron , Calum.Benson at sun.com,
Lin.Guo a
This case has been approved by PSARC today.
Sherry
--
Sherry Moore, Solaris Core Kernel http://blogs.sun.com/sherrym
function as expected?
>
> Regards,
> Alan Hargreaves
>
>
> Sherry Moore wrote:
>> The latest versions of all the documentation are available in the
>> final-materials directory at
>>
>> http://arc.opensolaris.org/caselog/PSARC/2009/330/
>>
>>
dumpadm.1m.diffmk.txt
mdb.1.diffmk.txt
Sherry
--
Sherry Moore, Solaris Core Kernel http://blogs.sun.com/sherrym
I am sponsoring this fasttrack for Dave Plauger and Steve Sistare. The
timer is set for next Tuesday August 18, 2009. Requesting Micro/Patch
binding.
The one-pager, project specification and man page diffs are available
in the materials directory.
Sherry Moore
Template Version
After consulting with the SMF team, I have updated the case write-up to
reflect the following changes:
1. Project name has been changed to
Introducing non-persistent property group config_ovr.
2. Boolean type property config_ovr/fastreboot_default will be used.
3. The library interface will
on to
scf_fastreboot_disable_transient(). Would that work?
Thanks,
Sherry
On Thu, Jun 04, 2009 at 08:56:13AM -0400, James Carlson wrote:
> Sherry Moore writes:
> > To enable the above usage models, a new non-persistent property
> > group "fastreboot_disable_np" will be introduc
I am sponsoring this case for Krishnendu Sadhukhan. Minor binding only.
Timer expires on June 10th, 2009.
Thanks,
Sherry
Template Version: @(#)sac_nextcase 1.68 02/23/09 SMI
This information is Copyright 2009 Sun Microsystems
1. Introduction
1.1. Project/Component Working Name:
Laten
stent property group fastreboot_disable_np
1.2. Name of Document Author/Supplier:
Author: Sherry Moore
1.3 Date of This Document:
03 June, 2009
2. Project Summary
2.1. Project Description:
To provide a mechanism to disable Fast Reboot for the next
reboot onl
, and
the case file has been updated and can be found where.
Sherry
--
Sherry Moore, Solaris Core Kernel http://blogs.sun.com/sherrym
I am sponsoring this case for Chad Mynhier and closing it as approved
automatic as it's simply a follow-on to PSARC/2009/105 to cover more
commands.
Thanks,
Sherry
--
Sherry Moore, Solaris Core Kernel http://blogs.sun.com/sherrym
Template Version: @(#)sac_nextcase 1.68 02/23/09 SMI
eft in current directory
> smit.script
>
> A desktop link for GNOME will be provided. The icon will depict a
> stick figure frozen in mid-step.
>
> The release binding is "Tight." The interfaces described are all
> "Difficult."
>
> Related OpenSolaris projects may include Visual Panels. The SMIT
> project team is not in contact with that team, and doesn't expect
> their agreement with this project, but would like to proceed anyway.
--
Sherry Moore, Solaris Core Kernel http://blogs.sun.com/sherrym
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" t
ce, that this case will be
> approved with no further objections.
>
>- -Garrett
--
Sherry Moore, Solaris Core Kernel http://blogs.sun.com/sherrym
been modified to look up the property values using
libscf so it's more straightforward.
Hope that answers your question.
Thanks,
Sherry
--
Sherry Moore, Solaris Core Kernel http://blogs.sun.com/sherrym
On Tue, Dec 09, 2008 at 09:21:26PM -0800, Gary Winiger wrote:
> > Liane Praza wrote:
> > > I'm submitting this fasttrack on behalf of Sherry Moore. It specifies
> > > Minor
> > > release binding.
>
> Perhaps I missed it in the man page diffs for rebo
On Wed, Jun 25, 2008 at 04:56:06AM -0700, Garrett D'Amore wrote:
> Sherry Moore wrote:
>> This is an e-mail note indicating that the dry-run information will be
>> suppressed from man pages, and are reclassified as Project Private per
>> disscussions between the proje
This is an e-mail note indicating that the dry-run information will be
suppressed from man pages, and are reclassified as Project Private per
disscussions between the project team, Jerry and Garrett.
Sherry
--
Sherry Moore, Solaris Core Kernel http://blogs.sun.com/sherrym
rd to interaction
between this project and PSARC 2008/195 "Validated Execution".
Thanks much,
Sherry
--
Sherry Moore, Solaris Core Kernel http://blogs.sun.com/sherrym
-- next part --
Driver Entry Pointsquiesce(9E)
NA
is asserted, that thread
> won't become active at the same time that the driver is in
> quiesce(9e) and there won't be two threads competing over
> the registers/resources of the device.
>
> -David
--
Sherry Moore, Solaris Core Kernel http://blogs.sun.com/sherrym
onal comments, and I will revise it
further.
Thanks,
Sherry
--
Sherry Moore, Solaris Core Kernel http://blogs.sun.com/sherrym
t problem as well.
Thanks,
Sherry
--
Sherry Moore, Solaris Core Kernel http://blogs.sun.com/sherrym
ck-free,
no-memory-allocation, do-the-bare-minimum manner to poke only the few
registers to stop all asynchronous writes to system memory and
interrupt generate. That's why the quisce() interface has an "arg"
field...
Thanks,
Sherry
--
Sherry Moore, Solaris Core Kernel http://blogs.sun.com/sherrym
/sample-driver-list.txt
Thanks,
Sherry
--
Sherry Moore, Solaris Core Kernel http://blogs.sun.com/sherrym
se its driver might not actually fully
> reset it on quiesce?) that a new kernel is replacing the old one. The
> old kernel was trusted and it can do signature verification of the new
> kernel. And the old kernel could pass to the new kernel any data the
> new kernel will need to ac
Hi Garrett,
> So one thing that is slightly confusing to me is, why do we need both
> ddi_no_quiesce(), and ddi_quiesce_not_supported()? And how is the entry
> point being NULL interpreted?
>
> It *seems* (and maybe I'm being naive here), that
> ddi_quiesce_not_supported() may not have much va
l DDI_QUIESCE. All the driver needs to guarantee is
that no more memory access will occur, and no more interrupts will be
generated post devo_quiesce(). That said, to avoid unnecessary code
duplication, the current DDI_QUIESCE implementation we have done for
most drivers are the same as that for DDI_SUSPEND, but minus the device
powering off part if exists.
Thanks,
Sherry
--
Sherry Moore, Solaris Core Kernel http://blogs.sun.com/sherrym
st of the memory is tested and
brought in dynamically.
This case delivers phase I.
Does that seem sufficient to you?
Garrett asked a similar question before, "Why can't the SPARC support
be done in parallel?" The answer is basically that, "It can, but I am
kind of single-threaded". :)
Thanks much,
Sherry
--
Sherry Moore, Solaris Core Kernel http://blogs.sun.com/sherrym
m, all bets are off anyway.
Thanks,
Sherry
--
Sherry Moore, Solaris Core Kernel http://blogs.sun.com/sherrym
ing used, which we can already do, then pass that
information to the new kernel via the memory list. Those ranges of
memory will not be used until the content has been saved.
We are still at experimental stage with post panic fast reboot. The
final implementation might differ.
Thanks,
--
Sher
You are reading the document correctly.
The implementation of this project will
1. verify the 32-bit unsigned checksum
2. verify that microcode is intended for the target CPU
before attempting to apply the microcode.
The checksum algorithm is very weak and I think it is only in place to
f
> Actually I meant to say
>
> The -i option requires write permission to the destination.
>
> It does not require secpolicy_ucode_update() privilege.
>
> Does that create a way for a user with privilege less than
> secpolicy_ucode_update() to arrange to update microcode by writin
> The -i option requires privilege to write to the destination.
>
> The -u option requires privilege secpolicy_ucode_update(),
> which is currently PRIV_ALL. The privilege checking will be
> performed by the driver. User with "Maintenance and Repair"
> profile will
> It seems like the extra layer of authenticity that 2007/355 provides by
> providing the updates via signed modules might to of value to our
> customers. Eventhough I believe in the almost 10 years that intel
> processor updates have been available there havn't been any trojan
> horses just obfus
> > 4.12. Dependencies:
> >
> > This project has dependency on the Intel microcode format as
> > described in Intel 64 and IA-32 Architectures Software
> > Developer's Manual Section 9-11 "Microcode Update Facilities".
> >
> Are you aware of anything in this dependency that might
> p
> > 4.5.2 Driver ucode_drv: Uncommitted
>
> Why not Project Private? I'm curious about who else might want or
> need to use the driver itself.
I don't anticipate anyone else to use the driver. I agree that
"Project Private" is more appropriate. I chose "Uncommitted" as it's
not very clear
> Do we know for sure whether AMD processors support a similar facility
> using the same interface?
AMD processors currently do not support microcode update by the OS. I
am actively pushing AMD for this capability on future AMD processors.
Hopefully I could influence the interface design. Howe
46 matches
Mail list logo
