On Thu, Feb 22, 2018 at 3:15 PM, bharat gohil <ghl.b...@gmail.com> wrote:

>
>
> On Thu, Feb 22, 2018 at 2:13 PM, bharat gohil <ghl.b...@gmail.com> wrote:
>
>>
>>
>> On Fri, Oct 6, 2017 at 6:59 PM, Julien Grall <julien.gr...@arm.com>
>> wrote:
>>
>>> Hello,
>>>
>>> On 03/10/17 08:05, bharat gohil wrote:
>>>
>>>>
>>>>
>>>> On Fri, Sep 29, 2017 at 11:12 PM, Julien Grall <julien.gr...@arm.com
>>>> <mailto:julien.gr...@arm.com>> wrote:
>>>>
>>>>
>>>>
>>>>     On 09/29/2017 09:15 AM, bharat gohil wrote:
>>>>
>>>>         Hello
>>>>
>>>>
>>>>     Hi,
>>>>
>>>>     Please avoid top-posting.
>>>>
>>>>         The patch didn't work in my case.
>>>>
>>>>
>>>>     The patch will be useful only if the compatible string in the DT of
>>>>     your UART is "snps,dw-apb-uart". What is the compatible string for
>>>> it?
>>>>
>>>> In my case, compatible string is "ns16550a".
>>>> Thanks,
>>>>
>>>
>>> Hmmm, looking back at the conversation your dom0 command line is:
>>>
>>> console=hvc0,921600n8 earlyprintk=xen debug ignore_loglevel rw
>>> root=/dev/mmcblk0p7
>>>
>>> earlyprintk=xen will do nothing as there are no Xen specific earlyprintk
>>> for Arm. For Dom0, I would recommend to use same same earlyprintk options
>>> as you would use on baremetal.
>>>
>>> This would allow you to get some early input if the kernel get stuck
>>> before the console has been setup.
>>>
>> I have tried your suggestion, I got following crash. It unable find
>> interrupt controller but this kernel working fine without Xen.
>> Do you have any suggestion?
>>
>> [2018-02-22 14:04:15] (XEN) DOM0: [    0.000000] OF: of_irq_init:
>> children remain, but no parents
>> [2018-02-22 14:04:15] (XEN) DOM0: [    0.000000] Kernel panic - not
>> syncing: No interrupt controller found.
>> [2018-02-22 14:04:15] (XEN) DOM0: [    0.000000] CPU: 0 PID: 0 Comm:
>> swapper/0 Not tainted 4.9.44+ #15
>> [2018-02-22 14:04:15] (XEN) DOM0: [    0.000000] Hardware name: XXXXX
>> board (DT)
>> [2018-02-22 14:04:15] (XEN) DOM0: [    0.000000] Call trace:
>> [2018-02-22 14:04:15] (XEN) DOM0: [    0.000000] [<ffffff8008089f88>]
>> dump_backtrace+0x0/0x1d8
>> [2018-02-22 14:04:15] (XEN) DOM0: [    0.000000] [<ffffff800808a184>]
>> show_stack+0x24/0x30
>> [2018-02-22 14:04:15] (XEN) DOM0: [    0.000000] [<ffffff800838a0e4>]
>> dump_stack+0x94/0xb8
>> [2018-02-22 14:04:15] (XEN) DOM0: [    0.000000] [<ffffff8008196da0>]
>> panic+0x124/0x270
>> [2018-02-22 14:04:15] (XEN) DOM0: [    0.000000] [<ffffff8008c92c08>]
>> init_IRQ+0x24/0x2c
>> [2018-02-22 14:04:15] (XEN) DOM0: [    0.000000] [<ffffff8008c909f8>]
>> start_kernel+0x230/0x388
>> [2018-02-22 14:04:15] (XEN) DOM0: [    0.000000] [<ffffff8008c901e0>]
>> __primary_switched+0x5c/0x64
>> [2018-02-22 14:04:15] (XEN) DOM0: [    0.000000] Rebooting in 1 seconds..
>>
>>
>
> SoC has different interrupt parent than GIC so I make GIC as interrupt
> parent and I am able to move ahead. update you once Dom0 boot completely.
>

System got hand and I got following traces related to energy aware
scheduler. Is Xen affected with guest scheduling mechanism? I have SoC
which has 4-Cortex A35 and 2-Cortex A72.

[    0.202545] Xen: initializing cpu4
[    0.202562] Invalid sched_group_energy for CPU4
[    0.202564] CPU4: update cpu_capacity 1024
[    0.202566] CPU4: Booted secondary processor [410fd041]
[    0.230197] Detected PIPT I-cache on CPU5
[    0.230202] CPU features: SANITY CHECK: Unexpected variation in
SYS_ID_AA64MMFR0_EL1. Boot CPU: 0x00000000101122, CPU5: 0x00000000001124
[    0.230250] Xen: initializing cpu5
[    0.230264] Invalid sched_group_energy for CPU5
[    0.230265] CPU5: update cpu_capacity 1024
[    0.230267] CPU5: Booted secondary processor [410fd041]
[    0.230373] Brought up 6 CPUs
[    0.234084] SMP: Total of 6 processors activated.
[    0.234108] CPU features: detected feature: 32-bit EL0 Support
[    0.234382] CPU: All CPU(s) started at EL1
[    0.234627] Invalid sched_group_energy for CPU5
[    0.234662] CPU5: update max cpu_capacity 1024
[    0.234680] Invalid sched_group_energy for Cluster5
[    0.234698] Invalid sched_group_energy for CPU4
[    0.234715] Invalid sched_group_energy for Cluster4
[    0.234733] Invalid sched_group_energy for CPU3
[    0.234750] Invalid sched_group_energy for Cluster3
[    0.234767] Invalid sched_group_energy for CPU2
[    0.234784] Invalid sched_group_energy for Cluster2
[    0.234801] Invalid sched_group_energy for CPU1
[    0.234819] Invalid sched_group_energy for Cluster1
[    0.234836] Invalid sched_group_energy for CPU0
[    0.234853] Invalid

I have SoC with 4 Cortex A35 and 2 Cortex A72.

>
>>> Furthermore, on a previous e-mail it has been mentioned that your
>>> problem might be because Linux will disable what it thinks unused clock. A
>>> way to prevent that (at least for debugging) is using add
>>> 'clk_ignore_unused' on the Linux command line.
>>>
>>> If the 2 suggestions above does not work, then you would have to
>>> instrument the kernel. When the hypervisor is build with debug enabled,
>>> there are is set a debug hvc provided. A useful one is hvc 0xfffd. For all
>>> of them, you can look at do_debug_trap in arch/arm/traps.c.
>>>
>>> I hope this will help.
>>>
>>> Cheers,
>>>
>>> --
>>> Julien Grall
>>>
>>
>>
>>
>> --
>> Regards,
>> Bharat Gohil
>> Sr.Software Engineer
>> bharat.go...@harman.com
>> +919427054633 <+91%2094270%2054633>
>>
>
>
>
> --
> Regards,
> Bharat Gohil
> Sr.Software Engineer
> bharat.go...@harman.com
> +919427054633 <+91%2094270%2054633>
>



-- 
Regards,
Bharat Gohil
Sr.Software Engineer
bharat.go...@harman.com
+919427054633
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Reply via email to