On Thu, Feb 22, 2018 at 3:15 PM, bharat gohil <[email protected]> wrote:
> > > On Thu, Feb 22, 2018 at 2:13 PM, bharat gohil <[email protected]> wrote: > >> >> >> On Fri, Oct 6, 2017 at 6:59 PM, Julien Grall <[email protected]> >> wrote: >> >>> Hello, >>> >>> On 03/10/17 08:05, bharat gohil wrote: >>> >>>> >>>> >>>> On Fri, Sep 29, 2017 at 11:12 PM, Julien Grall <[email protected] >>>> <mailto:[email protected]>> 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 >> [email protected] >> +919427054633 <+91%2094270%2054633> >> > > > > -- > Regards, > Bharat Gohil > Sr.Software Engineer > [email protected] > +919427054633 <+91%2094270%2054633> > -- Regards, Bharat Gohil Sr.Software Engineer [email protected] +919427054633
_______________________________________________ Xen-devel mailing list [email protected] https://lists.xenproject.org/mailman/listinfo/xen-devel
