|
[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
On 6/22/2015 6:20 PM, Julien Grall wrote:
> On 20/06/15 15:47, Peng Fan wrote:
>> On 6/20/2015 10:08 PM, Peng Fan wrote:
>>> Hi Julien,
>>>
>>> On 6/20/2015 6:19 PM, Julien Grall wrote:
>>>> Hi,
>>>>
>>>> On 19/06/2015 14:22, Peng Fan wrote:
>>>>> 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);
>>>>
>>>> By any chance, does your board has a another timer (i.e other than the
>>>> generic timer)?
>>>
>>> Yeah. There is a another timer whose rating is lower that generic timer.
>>>>
>>>> I would also track down to see who is adding this timer.
>>>>
>>>>> But after apply the above kernel patch, Dom0 Linux can handle shell
>>>>> input.
>>>>> Just have another question, How can Dom0 handle DMA for arm.
>>>>
>>>> When Xen is allocating the RAM bank for DOM0 we use a direct mapping
>>>> (i.e the Physical Address = Intermediate Address for the RAM). So DOM0
>>>> can perform DMA as on baremetal.
>>> Thanks. Current, without using rootfs in sd card, my Dom0 kernel can
>>> boot using ramfs. But if with sdhc which use ADMA, Dom0 kernel will
>>> panic. Below is the log:
>>>
>>> sdhci: Secure Digital Host Controller Interface driver
>>> sdhci: Copyright(c) Pierre Ossman
>>> sdhci-pltfm: SDHCI platform and OF driver helper
>>> Unable to handle kernel NULL pointer dereference at virtual address 00000000
>>> pgd = 80004000
>>> [00000000] *pgd=00000000
>>> Internal error: Oops: 5 [#1] PREEMPT SMP ARM
>>> Modules linked in:
>>> CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.14.38-02383-g5ccf32b-dirty #22
>>> task: 84074000 ti: 84078000 task.ti: 84078000
>>> PC is at bitmap_clear+0xc0/0xdc
>>> LR is at bitmap_clear+0x54/0xdc
>>> pc : [<8029deb8>] lr : [<8029de4c>] psr: 20000193
>>> sp : 84079d80 ip : 00000001 fp : 00000000
>>> r10: 00077fff r9 : 00000404 r8 : 00000001
>>> r7 : 00000001 r6 : 00000001 r5 : 00000000 r4 : ffffffff
>>> r3 : 00000001 r2 : 00000001 r1 : 20000193 r0 : 00000015
>>> Flags: nzCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment kernel
>>> Control: 10c53c7d Table: 8800406a DAC: 00000015
>>> Process swapper/0 (pid: 1, stack limit = 0x84078238)
>>> Stack: (0x84079d80 to 0x8407a000)
>>> 9d80: 80000113 00000000 87efa000 81109918 00001000 800197f8 84128558
>>> 00080008
>>> 9da0: 84079dec 000000d0 84bfeac0 84126c10 84126c10 ffffffff 00000404
>>> ffffffff
>>> 9dc0: 00000000 00000402 00000000 00000000 84126c10 80310ba8 ffffffff
>>> 00000000
>>> 9de0: 00000000 00000524 84078000 00000000 00000000 ffffffff ffffffff
>>> 84bfeac0
>>> 9e00: 84bfe800 8000b407 07eb0000 8116e0f8 00000000 804ee81c ffffffff
>>> ffffffff
>>> 9e20: 00000000 84126c10 84c92010 84bfeac0 00000000 84126c10 84126c00
>>> 84bfeac0
>>> 9e40: 84078030 804f08e4 804f03d8 84126c10 fffffdfb 8115401c 8115401c
>>> 00000000
>>> 9e60: 0000010f 80362330 803622ec 84126c10 811c8098 00000000 8115401c
>>> 80360b1c
>>> 9e80: 84126c10 8115401c 84126c44 00000000 80de1888 80360d28 00000000
>>> 8115401c
>>> 9ea0: 80360c9c 8035f10c 8406965c 84123634 8115401c 84c8bf80 8112f3c8
>>> 803602bc
>>> 9ec0: 80d08314 8115401c 00000006 8115401c 00000006 8116e080 8116e080
>>> 8036130c
>>> 9ee0: 00000000 80e00f78 00000006 800088dc 8400f900 80c94fe0 840bd480
>>> 80735184
>>> 9f00: 00000000 8116e080 0000150c 8012d430 00000000 811105b0 60000113
>>> 00000001
>>> 9f20: 87ffc576 8075ca38 0000010f 8004b0f0 80d66884 00000006 87ffc583
>>> 00000006
>>> 9f40: 811105a0 80e00f78 00000006 8116e080 8116e080 80da150c 0000010f
>>> 80df4154
>>> 9f60: 80df4148 80da1c4c 00000006 00000006 80da150c 9355553c 84079f9c
>>> 80731338
>>> 9f80: 00000000 00000000 80727254 00000000 00000000 00000000 00000000
>>> 00000000
>>> 9fa0: 00000000 8072725c 00000000 8000ecf8 00000000 00000000 00000000
>>> 00000000
>>> 9fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000
>>> 00000000
>>> 9fe0: 00000000 00000000 00000000 00000000 00000013 00000000 9355553c
>>> 9355553c
>>> [<8029deb8>] (bitmap_clear) from [<800197f8>]
>>> (__arm_dma_free.isra.18+0xe4/0x228)
>>> [<800197f8>] (__arm_dma_free.isra.18) from [<80310ba8>]
>>> (xen_swiotlb_free_coherent+0xfc/0x140)
>>> [<80310ba8>] (xen_swiotlb_free_coherent) from [<804ee81c>]
>>> (sdhci_add_host+0xb34/0xe64)
>>> [<804ee81c>] (sdhci_add_host) from [<804f08e4>]
>>> (sdhci_esdhc_imx_probe+0x50c/0x808)
>>> [<804f08e4>] (sdhci_esdhc_imx_probe) from [<80362330>]
>>> (platform_drv_probe+0x44/0xa4)
>>> [<80362330>] (platform_drv_probe) from [<80360b1c>]
>>> (driver_probe_device+0x120/0x25c)
>>> [<80360b1c>] (driver_probe_device) from [<80360d28>]
>>> (__driver_attach+0x8c/0x90)
>>> [<80360d28>] (__driver_attach) from [<8035f10c>]
>>> (bus_for_each_dev+0x60/0x94)
>>> [<8035f10c>] (bus_for_each_dev) from [<803602bc>]
>>> (bus_add_driver+0x148/0x1f0)
>>> [<803602bc>] (bus_add_driver) from [<8036130c>] (driver_register+0x78/0xf8)
>>> [<8036130c>] (driver_register) from [<800088dc>]
>>> (do_one_initcall+0xf8/0x144)
>>> [<800088dc>] (do_one_initcall) from [<80da1c4c>]
>>> (kernel_init_freeable+0x138/0x1d8)
>>> [<80da1c4c>] (kernel_init_freeable) from [<8072725c>] (kernel_init+0x8/0xf0)
>>> [<8072725c>] (kernel_init) from [<8000ecf8>] (ret_from_fork+0x14/0x3c)
>>> Code: 10866003 1206601f 10633006 11e02312 (e5953000)
>>> ---[ end trace f6f103bb73cc0503 ]---
>>> note: swapper/0[1] exited with preempt_count 1
>>> Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
>>>
>>> The piece code is at here:
>>> if (host->flags & SDHCI_USE_ADMA) {
>>> /*
>>> * We need to allocate descriptors for all sg entries
>>> * (128) and potentially one alignment transfer for
>>> * each of those entries.
>>> */
>>> host->adma_desc = dma_alloc_coherent(mmc_dev(host->mmc),
>>> ADMA_SIZE, &host->adma_addr,
>>> GFP_KERNEL);
>>> host->align_buffer = kmalloc(128 * 4, GFP_KERNEL);
>>> printk("%p %p\n", host->adma_desc, host->align_buffer); --->
>>> Here host->adma_desc is NULL
>>> if (!host->adma_desc || !host->align_buffer) {
>>> dma_free_coherent(mmc_dev(host->mmc), ADMA_SIZE,
>>> -->Trigger panic
>>> host->adma_desc, host->adma_addr);
>>> kfree(host->align_buffer);
>>>
>>> So dma_alloc_coherent failed, dma_free_coherent-->bitmap_clear trigger
>>> Dom0 panic. 128M memory is for Dom0, dma_alloc_coherent should not fail.
>>> Do you have any suggestions?
>>>
>
> Adding Stefano as he worked on DMA/swiotlb for ARM.
Already fixed. This is mmc/host/sdhci.c bug, I have a patch to fix this:
http://marc.info/?l=linux-kernel&m=143494451910852&w=2. Also I have a
configuration error, CONFIG_CMA_SIZE_MBYTES is too big 320M, but Dom0
mem only 128M.
>
>> Another problem comes to me, with 128M for Dom0, Dom0 can printk msg to
>> serial, but with "dom0_mem=1024M", I see nothing from serial for Dom0.
>
> Well, the RAM bank will surely be different between the 2 configurations.
>
> The DOM0 may have crashed before the console has effectively setup for
> multiple reason.
> Can you try this hacky patch [1], it will print everything using the Xen
> console.
>
> [1] http://lists.xen.org/archives/html/xen-devel/2014-10/msg03436.html
Thanks for this. Since there are two serial ports, I use uart2 for
earlyprintk.
I get why 512M or 1024M fail, but 128M and 256M is ok. But do not have
solution for this.
My platform's ddr memory is from 0x80000000 to 0xffffffff, total 2GB. My
xen boot args:
"
setenv xen_addr_r 0x80000000
setenv bootargs "console=dtuart
dtuart=/soc/aips-bus@30800000/serial@30860000 dom0_mem=256M"
fatload mmc 0:1 0x80000000 xen.image
fatload mmc 0:1 0x84000000 zImage
setenv kernel_addr_r 0x84000000
setenv fdt_high 0xffffffff
setenv fdt_addr 0x83000000
run loadfdt
fdt addr ${fdt_addr} 0x40000
fdt resize
fdt chosen
fdt set /chosen \#address-cells <1>
fdt set /chosen \#size-cells <1>
fdt mknod /chosen module@0
fdt set /chosen/module@0 compatible "xen,linux-zimage"
"xen,multiboot-module"
fdt set /chosen/module@0 reg <${kernel_addr_r} 0x${filesize}>
fdt set /chosen/module@0 bootargs "console=hvc0 ro root=/dev/mmcblk0p2
clk_ignore_unused uart_from_osc loglevel=8 earlyprintk"
bootz ${xen_addr_r} - ${fdt_addr}
"
I add debug log in this piece of code:
void __init sanity_check_meminfo(void)
{
phys_addr_t memblock_limit = 0;
int i, j, highmem = 0;
phys_addr_t vmalloc_limit = __pa(vmalloc_min - 1) + 1;
printk("vmalloc_min virt %x phys %x\n", vmalloc_min - 1,
__pa(vmalloc_min - 1));
printk("vmalloc_limit %x\n", vmalloc_limit);
If use 512M for Dom0, I found vmalloc_limit is 0xf800000, vmalloc_min is
0xef800000, This comes to a question, why __pa(vmalloc_min - 1) + will
make vmalloc_limit only 0xf800000 which is less than 128M. the pv stub
does some runtime fixup for virt_to_phys here.
Since vmalloc_limit is small, then all other memory bank in my platform
is recoginied as highmem, then arm_lowmem_limit is 0, then kernel panic:
"
dma_contiguous_reserve_area(size 1800000, base 00000000, limit 00000000)
CMA: failed to reserve 32 MiB
Memory policy: Data cache writealloc
Kernel panic - not syncing: ERROR: Failed to allocate 0x2000 bytes below
0x0.
"
0xffffffff - 0xef8000000 is about 264M. So I choose 256M as the Dom0
memory size. I do not have clear idea about this, current I am trying to
use xl to boot DomU, so just use 256M for Dom0 here.
>
> Regards,
>
Regards,
Peng.
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel
|
 |
Lists.xenproject.org is hosted with RackSpace, monitoring our |