Hi Mark/Will,
I would like to understand whether ARM linux community have plans to
support PSCI version 1.1 or not.
PSCI_1_1 specification introduced support for SYSTEM_RESET2 command and
this new command helps mobile devices to SYSTEM_WARM_RESET support.
Rebooting devices with warm reboot helps to capture the snapshot of the
ram contents for post-mortem analysis.
-Thanks, Prasad
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora
Forum,
Linux Foundation Collaborative Project
On 2019-04-30 14:44, Sodagudi Prasad wrote:
+Sudeep
> Hi Mark/Will,
>
> I would like to understand whether ARM linux community have plans to
> support PSCI version 1.1 or not.
> PSCI_1_1 specification introduced support for SYSTEM_RESET2 command
> and this new command helps mobile devices to SYSTEM_WARM_RESET
> support. Rebooting devices with warm reboot helps to capture the
> snapshot of the ram contents for post-mortem analysis.
I think, there is a recent discussion from Sudeep for the SYSTEM_RESET2
support.
https://patchwork.kernel.org/patch/10884345/
Hi Sudeep,
I was going through your discussion in the below list -
https://lore.kernel.org/lkml/[email protected]/
There is no provision to set up reboot mode dynamically instead kernel
command line parameter.
Looking for options to reboot device with warm reboot option when kernel
crashed.
panic() --> emergency_restart() --> machine_emergency_restart() -->
machine_restart(NULL);
It would nice if there is a config option to reboot the device either in
warm or cold in the case of kernel panic.
Calling machine_restart with a NULL parameter for kernel crash is
leading to devices cold reboot.
-Thanks, Prasad
>
> -Thanks, Prasad
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora
Forum,
Linux Foundation Collaborative Project
On Tue, Apr 30, 2019 at 05:07:31PM -0700, Sodagudi Prasad wrote:
> On 2019-04-30 14:44, Sodagudi Prasad wrote:
> +Sudeep
>
> > Hi Mark/Will,
> >
> > I would like to understand whether ARM linux community have plans to
> > support PSCI version 1.1 or not.
> > PSCI_1_1 specification introduced support for SYSTEM_RESET2 command
> > and this new command helps mobile devices to SYSTEM_WARM_RESET
> > support. Rebooting devices with warm reboot helps to capture the
> > snapshot of the ram contents for post-mortem analysis.
>
> I think, there is a recent discussion from Sudeep for the SYSTEM_RESET2
> support.
> https://patchwork.kernel.org/patch/10884345/
>
This has landed in -next, and hopefully must appear in v5.2
>
> Hi Sudeep,
>
> I was going through your discussion in the below list -
> https://lore.kernel.org/lkml/[email protected]/
>
> There is no provision to set up reboot mode dynamically instead kernel
> command line parameter.
> Looking for options to reboot device with warm reboot option when kernel
> crashed.
>
> panic() --> emergency_restart() --> machine_emergency_restart() -->
> machine_restart(NULL);
>
> It would nice if there is a config option to reboot the device either in
> warm or cold in the case of kernel panic.
I presume you prefer to do warm boot in case of panic to get a dump of
the memory to inspect ? If so, is kexec/kdump not the mechanism to
achieve that ?
I am just trying to understand the use case. Xilinx asked for the same
but never got to understand their use case.
--
Regards,
Sudeep
On 2019-05-01 02:49, Sudeep Holla wrote:
> On Tue, Apr 30, 2019 at 05:07:31PM -0700, Sodagudi Prasad wrote:
>> On 2019-04-30 14:44, Sodagudi Prasad wrote:
>> +Sudeep
>>
>> > Hi Mark/Will,
>> >
>> > I would like to understand whether ARM linux community have plans to
>> > support PSCI version 1.1 or not.
>> > PSCI_1_1 specification introduced support for SYSTEM_RESET2 command
>> > and this new command helps mobile devices to SYSTEM_WARM_RESET
>> > support. Rebooting devices with warm reboot helps to capture the
>> > snapshot of the ram contents for post-mortem analysis.
>>
>> I think, there is a recent discussion from Sudeep for the
>> SYSTEM_RESET2
>> support.
>> https://patchwork.kernel.org/patch/10884345/
>>
>
> This has landed in -next, and hopefully must appear in v5.2
>
>>
>> Hi Sudeep,
>>
>> I was going through your discussion in the below list -
>> https://lore.kernel.org/lkml/[email protected]/
>>
>> There is no provision to set up reboot mode dynamically instead kernel
>> command line parameter.
>> Looking for options to reboot device with warm reboot option when
>> kernel
>> crashed.
>>
>> panic() --> emergency_restart() --> machine_emergency_restart() -->
>> machine_restart(NULL);
>>
>> It would nice if there is a config option to reboot the device either
>> in
>> warm or cold in the case of kernel panic.
>
> I presume you prefer to do warm boot in case of panic to get a dump of
> the memory to inspect ? If so, is kexec/kdump not the mechanism to
> achieve that ?
Hi Sudeep,
Thanks for your response and sharing details about your patch.
<Sudeep> If so, is kexec/kdump not the mechanism to achieve that?
Qualcomm is having vendor specific solution to capture ram contents and
for offline analysis.
>
> I am just trying to understand the use case. Xilinx asked for the same
> but never got to understand their use case.
Here is the background -
Usually, power off drivers are overriding arm_pm_restart and
pm_power_off callbacks and registering with reboot notifier with some
priority for the reboot operations. Here is the Qualcomm poweroff
driver for reference.
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/power/reset/msm-poweroff.c
Before vendor chip set specific power off driver is probed,
arm_pm_restart functions pointer holds the psci_sys_reset function. Once
vendor power off driver is probed, vendor drivers can override the
arm_pm_restart function pointer.
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/firmware/psci.c#n562
Once vendor driver is probed, drivers can take care of devices warm or
hard reset configuration part properly. But there is a window from
start_kernel() to vendor specific driver probed, devices are getting
cold resets even if kernel crashed. This is due to arm_pm_restart
points to psci_sys_reset function by default. Is this problem clear
now?
Qualcomm downstream kernel has a lot of use cases with respect device
reset sequence and the downstream driver is much different from upstream
drivers. I think, the above-mentioned problem is common for all the
chipset vendors and it is not specific Qualcomm use cases. I have one
downstream solution to this problem but thought to bring up this problem
to the upstream community for a common solution, so that all the vendors
can use it.
I have modified below flow to avoid cold restart in the case of early
kernel panic.
panic() --> emergency_restart() --> machine_emergency_restart() -->
machine_restart(NULL);
-Thanks, Prasad
>
> --
> Regards,
> Sudeep
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora
Forum,
Linux Foundation Collaborative Project
On Wed, May 01, 2019 at 11:43:00AM -0700, Sodagudi Prasad wrote:
> On 2019-05-01 02:49, Sudeep Holla wrote:
> > On Tue, Apr 30, 2019 at 05:07:31PM -0700, Sodagudi Prasad wrote:
> > > On 2019-04-30 14:44, Sodagudi Prasad wrote:
[...]
> > >
> > > It would nice if there is a config option to reboot the device
> > > either in
> > > warm or cold in the case of kernel panic.
> >
> > I presume you prefer to do warm boot in case of panic to get a dump of
> > the memory to inspect ? If so, is kexec/kdump not the mechanism to
> > achieve that ?
>
> Hi Sudeep,
>
> Thanks for your response and sharing details about your patch.
>
> > If so, is kexec/kdump not the mechanism to achieve that?
> >
> Qualcomm is having vendor specific solution to capture ram contents and for
> offline analysis.
>
Ah OK.
> >
> > I am just trying to understand the use case. Xilinx asked for the same
> > but never got to understand their use case.
>
> Here is the background -
> Usually, power off drivers are overriding arm_pm_restart and pm_power_off
> callbacks and registering with reboot notifier with some priority for the
> reboot operations. Here is the Qualcomm poweroff driver for reference.
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/power/reset/msm-poweroff.c
>
> Before vendor chip set specific power off driver is probed, arm_pm_restart
> functions pointer holds the psci_sys_reset function. Once vendor power off
> driver is probed, vendor drivers can override the arm_pm_restart function
> pointer.
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/firmware/psci.c#n562
>
> Once vendor driver is probed, drivers can take care of devices warm or hard
> reset configuration part properly. But there is a window from
> start_kernel() to vendor specific driver probed, devices are getting cold
> resets even if kernel crashed. This is due to arm_pm_restart points to
> psci_sys_reset function by default. Is this problem clear now?
>
Too specific use case IMO and I am not sure if we need a generic solution
to deal with this. Anyways, I don't see any check in arch/psci specific
code for what you want, just ensure reboot_mode is set appropriately.
Post a patch and see what people have to say.
> Qualcomm downstream kernel has a lot of use cases with respect device reset
> sequence and the downstream driver is much different from upstream drivers.
> I think, the above-mentioned problem is common for all the chipset vendors
> and it is not specific Qualcomm use cases. I have one downstream solution
> to this problem but thought to bring up this problem to the upstream
> community for a common solution, so that all the vendors can use it.
>
May be or may be not, post the patch and let's see.
> I have modified below flow to avoid cold restart in the case of early kernel
> panic.
> panic() --> emergency_restart() --> machine_emergency_restart() -->
> machine_restart(NULL);
>
> -Thanks, Prasad
>
> >
> > --
> > Regards,
> > Sudeep
>
> --
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> Linux Foundation Collaborative Project
On 2019-05-02 02:05, Sudeep Holla wrote:
> On Wed, May 01, 2019 at 11:43:00AM -0700, Sodagudi Prasad wrote:
>> On 2019-05-01 02:49, Sudeep Holla wrote:
>> > On Tue, Apr 30, 2019 at 05:07:31PM -0700, Sodagudi Prasad wrote:
>> > > On 2019-04-30 14:44, Sodagudi Prasad wrote:
>
> [...]
>
>> > >
>> > > It would nice if there is a config option to reboot the device
>> > > either in
>> > > warm or cold in the case of kernel panic.
>> >
>> > I presume you prefer to do warm boot in case of panic to get a dump of
>> > the memory to inspect ? If so, is kexec/kdump not the mechanism to
>> > achieve that ?
>>
>> Hi Sudeep,
>>
>> Thanks for your response and sharing details about your patch.
>>
>> > If so, is kexec/kdump not the mechanism to achieve that?
>> >
>> Qualcomm is having vendor specific solution to capture ram contents
>> and for
>> offline analysis.
>>
>
> Ah OK.
>
>> >
>> > I am just trying to understand the use case. Xilinx asked for the same
>> > but never got to understand their use case.
>>
>> Here is the background -
>> Usually, power off drivers are overriding arm_pm_restart and
>> pm_power_off
>> callbacks and registering with reboot notifier with some priority for
>> the
>> reboot operations. Here is the Qualcomm poweroff driver for
>> reference.
>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/power/reset/msm-poweroff.c
>>
>> Before vendor chip set specific power off driver is probed,
>> arm_pm_restart
>> functions pointer holds the psci_sys_reset function. Once vendor power
>> off
>> driver is probed, vendor drivers can override the arm_pm_restart
>> function
>> pointer.
>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/firmware/psci.c#n562
>>
>> Once vendor driver is probed, drivers can take care of devices warm or
>> hard
>> reset configuration part properly. But there is a window from
>> start_kernel() to vendor specific driver probed, devices are getting
>> cold
>> resets even if kernel crashed. This is due to arm_pm_restart points
>> to
>> psci_sys_reset function by default. Is this problem clear now?
>>
>
> Too specific use case IMO and I am not sure if we need a generic
> solution
> to deal with this. Anyways, I don't see any check in arch/psci specific
> code for what you want, just ensure reboot_mode is set appropriately.
> Post a patch and see what people have to say.
Hi Sudeep,
Yes. With your system_reset2 command support addition, just configuring
the reboot_mode is good enough.
-Thanks, Prasad
>
>> Qualcomm downstream kernel has a lot of use cases with respect device
>> reset
>> sequence and the downstream driver is much different from upstream
>> drivers.
>> I think, the above-mentioned problem is common for all the chipset
>> vendors
>> and it is not specific Qualcomm use cases. I have one downstream
>> solution
>> to this problem but thought to bring up this problem to the upstream
>> community for a common solution, so that all the vendors can use it.
>>
>
> May be or may be not, post the patch and let's see.
>
>> I have modified below flow to avoid cold restart in the case of early
>> kernel
>> panic.
>> panic() --> emergency_restart() --> machine_emergency_restart() -->
>> machine_restart(NULL);
>>
>> -Thanks, Prasad
>>
>> >
>> > --
>> > Regards,
>> > Sudeep
>>
>> --
>> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora
>> Forum,
>> Linux Foundation Collaborative Project
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora
Forum,
Linux Foundation Collaborative Project
Some platforms may need warm reboot support when kernel crashed
for post mortem analysis instead of cold reboot. So use config
CONFIG_WARM_REBOOT_ON_PANIC and SYSTEM_RESET2 psci command
support for warm reset.
Signed-off-by: Prasad Sodagudi <[email protected]>
---
kernel/panic.c | 4 ++++
lib/Kconfig.debug | 10 ++++++++++
2 files changed, 14 insertions(+)
diff --git a/kernel/panic.c b/kernel/panic.c
index c1fcaad..6ab6675 100644
--- a/kernel/panic.c
+++ b/kernel/panic.c
@@ -198,6 +198,10 @@ void panic(const char *fmt, ...)
console_verbose();
bust_spinlocks(1);
+#ifdef CONFIG_WARM_REBOOT_ON_PANIC
+ /* Configure for warm reboot instead of cold reboot. */
+ reboot_mode = REBOOT_WARM;
+#endif
va_start(args, fmt);
len = vscnprintf(buf, sizeof(buf), fmt, args);
va_end(args);
diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
index d695ec1..2a727d8 100644
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@ -1000,6 +1000,16 @@ config PANIC_TIMEOUT
value n > 0 will wait n seconds before rebooting, while a timeout
value n < 0 will reboot immediately.
+config WARM_REBOOT_ON_PANIC
+ bool "Warm reboot instead of cold reboot for panic"
+ default n
+ help
+ Some vendor platform may need warm reboot instead of cold reboot
+ for debugging. Before vendor specific power off driver is
+ probed, platform always gets cold reset. By setting Y here and
+ support for PSCI V1.1 is present from firmware, platform would
+ get warm reset instead of cold reset.
+
config SCHED_DEBUG
bool "Collect scheduler debugging info"
depends on DEBUG_KERNEL && PROC_FS
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,\na Linux Foundation Collaborative Project
On Wed, May 08, 2019 at 06:47:12PM -0700, Prasad Sodagudi wrote:
> Some platforms may need warm reboot support when kernel crashed
> for post mortem analysis instead of cold reboot. So use config
> CONFIG_WARM_REBOOT_ON_PANIC and SYSTEM_RESET2 psci command
> support for warm reset.
>
Please drop all the references to PSCI and SYSTEM_RESET2 including
in subject. This is more generic and PSCIv1.1 with SYSTEM_RESET2 can
make use of it.
> Signed-off-by: Prasad Sodagudi <[email protected]>
> ---
> kernel/panic.c | 4 ++++
> lib/Kconfig.debug | 10 ++++++++++
> 2 files changed, 14 insertions(+)
>
> diff --git a/kernel/panic.c b/kernel/panic.c
> index c1fcaad..6ab6675 100644
> --- a/kernel/panic.c
> +++ b/kernel/panic.c
> @@ -198,6 +198,10 @@ void panic(const char *fmt, ...)
>
> console_verbose();
> bust_spinlocks(1);
> +#ifdef CONFIG_WARM_REBOOT_ON_PANIC
> + /* Configure for warm reboot instead of cold reboot. */
> + reboot_mode = REBOOT_WARM;
> +#endif
> va_start(args, fmt);
> len = vscnprintf(buf, sizeof(buf), fmt, args);
> va_end(args);
> diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
> index d695ec1..2a727d8 100644
> --- a/lib/Kconfig.debug
> +++ b/lib/Kconfig.debug
> @@ -1000,6 +1000,16 @@ config PANIC_TIMEOUT
> value n > 0 will wait n seconds before rebooting, while a timeout
> value n < 0 will reboot immediately.
>
> +config WARM_REBOOT_ON_PANIC
> + bool "Warm reboot instead of cold reboot for panic"
> + default n
> + help
> + Some vendor platform may need warm reboot instead of cold reboot
> + for debugging. Before vendor specific power off driver is
> + probed, platform always gets cold reset. By setting Y here and
> + support for PSCI V1.1 is present from firmware, platform would
> + get warm reset instead of cold reset.
> +
Ditto here, drop PSCI reference. Since it's being pushed as generic
solution, expecting anyone reading this to understand what is this PSCI
makes no sense and may be even confusing.
--
Regards,
Sudeep
Hi,
On Wed, May 08, 2019 at 06:47:12PM -0700, Prasad Sodagudi wrote:
> Some platforms may need warm reboot support when kernel crashed
> for post mortem analysis instead of cold reboot. So use config
> CONFIG_WARM_REBOOT_ON_PANIC and SYSTEM_RESET2 psci command
> support for warm reset.
Please see commit b287a25a7148 - you can now use kernel command
line option reboot=panic_warm to get this.
A.
On 2019-05-16 11:29, Aaro Koskinen wrote:
> Hi,
>
> On Wed, May 08, 2019 at 06:47:12PM -0700, Prasad Sodagudi wrote:
>> Some platforms may need warm reboot support when kernel crashed
>> for post mortem analysis instead of cold reboot. So use config
>> CONFIG_WARM_REBOOT_ON_PANIC and SYSTEM_RESET2 psci command
>> support for warm reset.
>
> Please see commit b287a25a7148 - you can now use kernel command
> line option reboot=panic_warm to get this.
Thanks Aaro. Yes. I can use this option. Thanks Sudeep and all for
discussing.
>
> A.
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora
Forum,
Linux Foundation Collaborative Project