Hi,

Im am working on a ARM imx6ul board with custom kernel. I have some freeze 
issue. I was able to detect
that it is a kernel panic. I would like to be able to save across reboot kernel 
panic log thanks to
ramoops feature. I dont have physical access to the board during the kernel 
panic. Only way for me to
understand and fix the issue is to save and store the kernel panic log to send 
the log to a server later.

To enable ramoops, I update my kernel config :

[arthur * 4.1.15_2.0.0_nano] cat output/build/linux-4.1.15_2.1.0_v17/.config | 
grep PSTORE
CONFIG_PSTORE=y
CONFIG_PSTORE_CONSOLE=y
# CONFIG_PSTORE_PMS

I configure the ramoops platform data in the board config file of the kernel 
tree :

arthur * 4.1.15_2.0.0_nano] git diff arch/arm
diff --git a/arch/arm/mach-imx/mach-imx6ul.c b/arch/arm/mach-imx/mach-imx6ul.c
index dcabfb1..5b1d74c 100644
--- a/arch/arm/mach-imx/mach-imx6ul.c
+++ b/arch/arm/mach-imx/mach-imx6ul.c
@@ -23,6 +23,22 @@
 #include "common.h"
 #include "cpuidle.h"
 #include "hardware.h"
+#include <linux/pstore_ram.h>
+#include <linux/memblock.h>
+static struct ramoops_platform_data ramoops_data = {
+       .mem_address    = 0x80000000,
+       .mem_size       = 0x00005000, // 5 Mb ??
+       .record_size    = 0x00001000, // 1 Mb
+       .dump_oops      = 1,
+};
+
+static struct platform_device ramoops_dev = {
+        .name = "ramoops",
+        .dev = {
+                .platform_data = &ramoops_data,
+        },
+};
+

static void __init imx6ul_enet_clk_init(void)
{
@@ -169,6 +185,15 @@ static inline void imx6ul_enet_init(void)
static void __init imx6ul_init_machine(void)
{
        struct device *parent;
+       int ret;
+
+       ret = platform_device_register(&ramoops_dev);
+       if (ret) {
+               printk(KERN_ERR "unable to register platform device\n");
+               return;
+       }
+       /* Do I need that ???? */
+       //memblock_reserve(ramoops_data.mem_address, ramoops_data.mem_size);

        parent = imx_soc_device_init();
                if (parent == NULL)


Then when I tried to mount the pstore partition :


# mount -t pstore -o kmsg_bytes=1000 - /sys/fs/pstore
TUTU size : -335633131
------------[ cut here ]------------
WARNING: CPU: 0 PID: 547 at mm/page_alloc.c:2668 
__alloc_pages_nodemask+0x19c/0x838()
Modules linked in: bcmdhd
CPU: 0 PID: 547 Comm: mount Not tainted 4.1.15 #27
Hardware name: Freescale i.MX6 Ultralite (Device Tree)
[<800144bc>] (unwind_backtrace) from [<800121ec>] (show_stack+0x10/0x14)
[<800121ec>] (show_stack) from [<80034444>] (warn_slowpath_common+0x80/0xac)
[<80034444>] (warn_slowpath_common) from [<8003450c>] 
(warn_slowpath_null+0x1c/0x24)
[<8003450c>] (warn_slowpath_null) from [<800a2704>] 
(__alloc_pages_nodemask+0x19c/0x838)
[<800a2704>] (__alloc_pages_nodemask) from [<800b5a60>] 
(kmalloc_order+0x10/0x20)
[<800b5a60>] (kmalloc_order) from [<80253fa8>] 
(persistent_ram_save_old+0x118/0x134)
[<80253fa8>] (persistent_ram_save_old) from [<80253154>] 
(ramoops_get_next_prz+0x6c/0x78)
[<80253154>] (ramoops_get_next_prz) from [<802531a0>] 
(ramoops_pstore_read+0x40/0x254)
[<802531a0>] (ramoops_pstore_read) from [<80252990>] 
(pstore_get_records+0xa8/0x2e0)
[<80252990>] (pstore_get_records) from [<80251da8>] 
(pstore_fill_super+0xa8/0xbc)
[<80251da8>] (pstore_fill_super) from [<800db540>] (mount_single+0x88/0xac)
[<800db540>] (mount_single) from [<800db5d4>] (mount_fs+0x14/0xa4)
[<800db5d4>] (mount_fs) from [<800f4688>] (vfs_kern_mount+0x48/0x114)
[<800f4688>] (vfs_kern_mount) from [<800f7744>] (do_mount+0x198/0xc28)
[<800f7744>] (do_mount) from [<800f84fc>] (SyS_mount+0x74/0xa0)
[<800f84fc>] (SyS_mount) from [<8000f2a0>] (ret_fast_syscall+0x0/0x3c)
persistent_ram: failed to allocate buffer

In the function persistent_ram_save_old for unknow reason the size is negative.
Do I miss something ? I also try to patch my kernel to use device tree for 
ramoops
but nothing was working correctly. Same result if I tried to set ramoops 
settings
through kernel parameter.

When I try to use other value for ramoops configuration, my kernel is not able 
to
boot anymore.

Thanks,
Arthur.

_______________________________________________
Kernelnewbies mailing list
[email protected]
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Reply via email to