From: Brian King <brking@linux.vnet.ibm.com>
To: Stewart Smith <stewart@linux.vnet.ibm.com>,
Michael Ellerman <mpe@ellerman.id.au>,
"Guilherme G. Piccoli" <gpiccoli@linux.vnet.ibm.com>
Cc: linuxppc-dev@ozlabs.org, "dougmill@us.ibm.com" <dougmill@us.ibm.com>
Subject: Re: [PATCH] powerpc/powernv: Turn on SCSI_AACRAID in powernv_defconfig
Date: Fri, 23 Feb 2018 13:41:00 -0600 [thread overview]
Message-ID: <f7060a3e-9a86-8c90-f102-c3b5b49b4ea3@linux.vnet.ibm.com> (raw)
In-Reply-To: <87inaopnlh.fsf@linux.vnet.ibm.com>
On 02/22/2018 06:16 PM, Stewart Smith wrote:
> Michael Ellerman <mpe@ellerman.id.au> writes:
>> Brian King <brking@linux.vnet.ibm.com> writes:
>>> On 09/03/2017 06:19 PM, Stewart Smith wrote:
>>>> Michael Ellerman <mpe@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
--
Brian King
Power Linux I/O
IBM Linux Technology Center
prev parent reply other threads:[~2018-02-23 19:41 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-08-28 5:56 [PATCH] powerpc/powernv: Turn on SCSI_AACRAID in powernv_defconfig Michael Ellerman
2017-08-28 13:16 ` Guilherme G. Piccoli
2017-08-29 11:22 ` Michael Ellerman
2017-08-29 13:03 ` Guilherme G. Piccoli
2017-08-30 11:07 ` Michael Ellerman
2017-08-30 12:47 ` Guilherme G. Piccoli
2017-08-31 9:48 ` Stewart Smith
2017-08-31 12:37 ` Michael Ellerman
2017-08-31 15:31 ` Brian King
2017-09-01 5:23 ` Michael Ellerman
2017-09-03 23:19 ` Stewart Smith
2017-09-06 13:42 ` Brian King
2018-02-22 22:19 ` Michael Ellerman
2018-02-23 0:16 ` Stewart Smith
2018-02-23 19:41 ` Brian King [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=f7060a3e-9a86-8c90-f102-c3b5b49b4ea3@linux.vnet.ibm.com \
--to=brking@linux.vnet.ibm.com \
--cc=dougmill@us.ibm.com \
--cc=gpiccoli@linux.vnet.ibm.com \
--cc=linuxppc-dev@ozlabs.org \
--cc=mpe@ellerman.id.au \
--cc=stewart@linux.vnet.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).