[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] Dom0 kernel panic when porting xen to new arm soc




Hi,

On 6/18/2015 10:54 PM, Ian Campbell wrote:
On Thu, 2015-06-18 at 22:09 +0800, Peng Fan wrote:
Hi,

I am porting xen to an Cortex-A7 soc and met Dom0 kernel panic. I have
no clear idea about why Dom0 kernel panic.
Have you confirmed that this same kernel runs reliably natively on this
platform?
Yeah. With XEN related configuration, the kernel can run natively on the platform.


[...]
/ # Unable to handle kernel NULL pointer dereference at virtual address
00000000
pgd = 84f1c000
[00000000] *pgd=8cf15831, *pte=00000000, *ppte=00000000
Internal error: Oops: 80000007 [#1] PREEMPT SMP ARM
Modules linked in:
CPU: 0 PID: 89 Comm: sh Not tainted 3.14.28-01780-g281e5c1-dirty #269
task: 84c07a80 ti: 84f02000 task.ti: 84f02000
PC is at 0x0
LR is at call_timer_fn.isra.33+0x24/0x88
pc : [<00000000>]    lr : [<80038b38>]    psr: 20000113
Your kernel has jumped to address 0x0 for some reason. You should use
gdb or something to examine you vmlinux file and try and figure out what
LR is doing, which may give you a hint as to why it is apparently
jumping to address zero.
I add such piece of code the linux kernel version 3.14.38. The panic disappears.

diff --git a/kernel/timer.c b/kernel/timer.c
index 38f0d40..4a025cc 100644
--- a/kernel/timer.c
+++ b/kernel/timer.c
@@ -1175,6 +1175,10 @@ static inline void __run_timers(struct tvec_base *base)

                        base->running_timer = timer;
                        detach_expired_timer(timer, base);
+                       if (!fn) {
+ printk("fn is null why????\n"); ----> This log only shows once. Not sure why fn is null and only once.
+                               continue;
+                       }

                        if (irqsafe) {
                                spin_unlock(&base->lock);

(XEN) Latest ChangeSet: Mon Jun 15 18:25:34 2015 +0800 git:c01e139-dirty
What changes have you made to your version of Xen? c01e139 is not an
upstream commit.
I only add an uart driver and a platform file. The platform part is very simple:
PLATFORM_START(imx7d, "i.MX 7Dual")
    .compatible = imx7d_dt_compat,
.smp_init = imx7d_smp_init, --> Actually I disabled this, since in dts, only one cpu node enabled.
    .cpu_up = cpu_up_send_sgi,
    /* Use IRAM base, not sure */
#if 0
    .dom0_gnttab_start = 0x00900000,
    .dom0_gnttab_size = 0x20000,
#endif
PLATFORM_END
I am not sure whether this realted to timer, the timer dts:
I think it looks like a software timer thing in the kernel rather than a
h/w timer thing.

The Dom0 kernel is also configured with " CONFIG_ARM_ARCH_TIMER=y", will
this incur errors? Or should Dom0 kernel not use arm arch timer?
Guests on Xen (including dom0) _should_ be using the arch timer.

Ian.

Not sure whether it relates to the uart driver that Julien suspected. But after apply the above kernel patch, Dom0 Linux can handle shell input.
Just have another question, How can Dom0 handle DMA for arm.

Thanks,
Peng.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.