On 02/22/2018 06:16 PM, Stewart Smith wrote:
> Michael Ellerman <m...@ellerman.id.au> writes:
>> Brian King <brk...@linux.vnet.ibm.com> writes:
>>> On 09/03/2017 06:19 PM, Stewart Smith wrote:
>>>> Michael Ellerman <m...@ellerman.id.au> writes:
>>>>>> 2. On a bare metal machine, if you set ipr.fast_reboot=1 on the skiboot
>>>>>>    kernel, then we should also avoid resetting the ipr adapter, so ipr
>>>>>>    init on the kernel being kexec booted from skiboot should be 
>>>>>> extremely fast. 
>>>>> OK, I didn't know that was an option, so that might help.
>>>>>> ...
>>>>>> If you've got cases where ipr init is taking a long time, I'd be
>>>>>> interested to know what scenarios are the most annoying to see if there
>>>>>> is any opportunity to improve.
>>>>> Yeah booting bare metal is where I see it (not using ipr.fast_reboot).
>>>> Hrm... We should probably enable that by default for petitboot then.
>>>> It'd at least cut some time off booting straight through to OS.
>>> Agreed. I'd be interested to hear if that helps address the issue
>>> Michael is seeing.
>>> You can easily test this by exiting to a petitboot shell:
>>> echo 1 > /sys/module/ipr/parameters/fast_reboot
>>> Then go back to petitboot and boot the OS.
>> Just following up on this (!).
>> This does work, and I've now been running it in my CI for about a month
>> (~1000 boots) with no problems.
>> You can also make it persistent by doing:
>>   $ nvram -p ibm,skiboot --update-config bootargs="ipr.fast_reboot=1"
> Okay, cool. https://github.com/open-power/op-build/pull/1900 will set it
> in firmware - we may as well run with this and fix any bugs we find.
> Any reason why it isn't the default behaviour?

The primary reason this isn't the default setting is because it would cause
undesired behavior on system reboots. On a kexec reboot, since the PCIe slots
don't get power cycled or even hit with PERST, we can simply quiesce devices
and pick them up at the other side of the kexec. On a real reboot where the
firmware or hardware may end up doing a PERST or power cycle, we need to tell 
the ipr
adapters that is coming and let them shutdown gracefully. If we don't,
we will likely be OK in the single adapter configuration in most scenarios,
but for a dual ipr adapter configuration, we can then end up with undesired
adapter failovers occurring due to the unexpected power offs / resets, which
can then end up extending the next boot.


Brian King
Power Linux I/O
IBM Linux Technology Center

Reply via email to