On Wed, Jun 27, 2018 at 9:33 PM, Sricharan R <sricharan@xxxxxxxxxxxxxx> wrote:
> Hi Andy,
>
> On 6/27/2018 2:47 AM, Andy Strohman wrote:
>> On Sun, Jun 17, 2018 at 11:31 PM, <sricharan@xxxxxxxxxxxxxx> wrote:
>>> Hi Andy,
>>>
>>> On 2018-06-16 06:37, Andy Strohman wrote:
>>>>
>>>> Hi,
>>>>
>>>> I'm trying to get kexec to work consistently for ipq4019. I load
>>>> the crash kernel like this:
>>>>
>>>> kexec --type zImage -p zImage-initramfs
>>>> --dtb=image-qcom-ipq4019-eap1300.dtb --append="maxcpus=1
>>>> reset_devices" --image-size=34419456
>>>>
>>>> I have reserved 64MB of memory for the crash kernel with parameter:
>>>> crashkernel=64M
>>>>
>>>> This seems to work ~70% of the time. When it doesn't work, I see the
>>>> "bye!" message followed by a 5-10 second hang without output. Then
>>>> the machine resets.
>>>>
>>>> I've been testing with:
>>>> echo c > /proc/sysrq-trigger
>>>>
>>>> Does anyone have an idea of what may be causing the failures or how
>>>> to troubleshoot this?
>>>>
>>>
>>> I will try to reproduce this and get back to you shortly.
>>>
>>> Regards,
>>> Sricharan
>>>
>>>
>>>> I'm using OpenWRT with kernel 4.14.37. I added the following patch
>>>> in order to load the crash kernel:
>>>>
>>>> --- a/arch/arm/mach-qcom/platsmp.c
>>>> +++ b/arch/arm/mach-qcom/platsmp.c
>>>> @@ -332,6 +332,12 @@ static void __init qcom_smp_prepare_cpus
>>>> }
>>>> }
>>>>
>>>> +/* Needed by kexec and platform_can_cpu_hotplug() */
>>>> +int qcom_cpu_kill(unsigned int cpu)
>>>> +{
>>>> + return 1;
>>>> +}
>>>> +
>>>> static const struct smp_operations smp_msm8660_ops __initconst = {
>>>> .smp_prepare_cpus = qcom_smp_prepare_cpus,
>>>> .smp_secondary_init = qcom_secondary_init,
>>>> @@ -358,6 +364,7 @@ static const struct smp_operations qcom_
>>>> .smp_boot_secondary = kpssv2_boot_secondary,
>>>> #ifdef CONFIG_HOTPLUG_CPU
>>>> .cpu_die = qcom_cpu_die,
>>>> + .cpu_kill = qcom_cpu_kill,
>>>> #endif
>>>> };
>>>> CPU_METHOD_OF_DECLARE(qcom_smp_kpssv2, "qcom,kpss-acc-v2",
>>>> &qcom_smp_kpssv2_ops);
>>>>
>>>>
>>>> Thanks,
>>>>
>>>> Andy
>>
>> Hi Sricharan,
>>
>> Thanks for your response. Did you get a chance to try this out? If
>> so, were you able to reproduce?
>>
>
> I have been trying to kexec while chroot'ing for a different reason.
> I did not observe a issue so far. But that is with a 4.4.60 openwrt kernel.
> Can you point me a link to the kernel that you are trying with ?
>
> Regards,
> Sricharan
>
> --
> "QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
Sricharan,
I am using https://git.openwrt.org/openwrt/openwrt.git, commit:
ac70ac3532fefa78c944d8a26c8df0ca5d88d04e
Can you provide me a link to the source that you are using?
I think my problem is that callback cpu_kill within struct
smp_operations is not properly implemented in
arch/arm/mach-qcom/platsmp.c. I added a dummy function that just
returns 1 to allow loading the crash kernel. That is the patch in my
original email in this thread. I gave this approach a try because I
saw another SUBARCH doing the same, but I think it's inadequate.
After reading the surrounding code,
https://patchwork.ozlabs.org/patch/207562/ and
https://patchwork.kernel.org/patch/1925071/ , I now believe that I
need to power down CPUs in cpu_kill. Since I don't have the datasheet
for ipq4019, I'm not sure how to do that. If you have any advise
regarding this, that would great.
When I boot the machine with nr_cpus=1, kexec always works. It
also seems to work reliably if I taskset the process that triggers the
crash to cpu 0.
Thanks,
Andy
--
http://www.uplevelsystems.com <http://www.uplevelsystems.com>
--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
