Hi Bill,
> > reboot -f (1M) Committed To initiate a fast reboot.
> >
> > reboot -f -e (1M) Committed To fast reboot to a different
> > BE.
> ...
>
> > For the fast reboot case, if DDI_FAILURE is returned for the
> > DDI_QUIESCE cmd, regular reboot path will be taken.
>
> if reboot -f -e is used, does this mean that a different BE than the
> desired BE will be booted?
It means a different BE than the *default* BE will be booted.
> Could we decouple -e and -f?
Technically yes. It will basically be "luactivate BE; init 6", or
manually setting the default in menu.lst, or finding out the
corresponding menu item number in menu.lst for the desired BE, and do
"reboot number".
However, luactivate explicitly disassociates itself from reboot.
**********************************************************************
The target boot environment has been activated. It will be used when you
reboot. NOTE: You MUST NOT USE the reboot, halt, or uadmin commands. You
MUST USE either the init or the shutdown command when you reboot. If you
do not use either init or shutdown, the system will not boot using the
target BE.
**********************************************************************
I don't know the history behind the requirement stated above. I will
contact the Live Upgrade team to see if's OK to support -e for regular
reboot as well. If anybody knows the answer, feel free to chime in.
> Is there a meaningful difference between DDI_QUIESCE and DDI_SUSPEND?
>
> The proposed quiesce/DDI_QUIESCE says:
>
> If cmd is set to DDI_QUIESCE, quiesce() is used to stop devices
> from generating interrupts or modify or access memory.
>
> the existing detach/DDI_SUSPEND is documented as:
>
> If cmd is set to DDI_SUSPEND, detach() is used to suspend
> all activity of a device before power is (possibly) removed
> from the device. The steps associated with suspension must
> include putting the underlying device into a quiescent state
> so that it will not generate interrupts or modify or access
> memory.
That's an excellent question! The meaningful differences are in the
parts that you didn't quote.
For DDI_SUSPEND
- "It will be issued only to devices which have a reg
property or which export a pm-hardware- state property with the
value needs-suspend-resume."
Some of us are not convinced that devices meeting the above
conditions are the only ones that need to be quiesced because
drivers without a reg property can still do in-bound DMA. We felt
that it's better to leave the decision to the driver authors. A
driver that does not manage devices that need to be quiesed must
explicitly set its devo_quiesce op to ddi_no_quiesce() (or
whatever name we settle on) to indicate that there's no need to
quiesce.
- "It must save the hardware state of the device to memory and
block incoming or existing requests until attach() is called with
DDI_RESUME."
Saving hardware state is not a requirement for DDI_QUIESCE.
With some devices, the hardware is powered off by the driver's
implementation for DDI_SUSPEND. For DDI_QUIESCE, power needs to stay
on.
The semantics for DDI_QUIESCE are much more relaxed than that for
DDI_SUSPEND. Not being able to detach from a software framework is not
a condition to fail 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
