kdump for ARM Linux?

kdump for ARM Linux?

[Andy Nicholas]

Hello, hopefully this is the correct mailing list for this question:

I'm working on a derivative of the mainline Linux 3.8 kernel and I'm trying
to enable ARM kdump functionality to collect crashdumps when we have kernel
problems. But, there's some kind of unresolved issue in
arch/arm/mm/ioremap.c which prevents /proc/vmcore from being able to
function properly. I checked and this appears to still be in kernel.org
Linux 3.13. The target platform is a regular, recent ARMv7 compatible chip. 

Has this issue been addressed in any version of an ARM Linux kernel? Or, is
there a work-around? If not, how does a crashdump file get generated when/if
the kernel crashes or a driver faults?

>> WARNING: at arch/arm/mm/ioremap.c:244
__arm_ioremap_pfn_caller+0x1d8/0x1f0()
>> Modules linked in:
>> [<c0016660>] (unwind_backtrace+0x0/0x138) from [<c0020480>]
(warn_slowpath_common+0x4c/0x64)
>> [<c0020480>] (warn_slowpath_common+0x4c/0x64) from [<c00204b4>]
(warn_slowpath_null+0x1c/0x24)
>> [<c00204b4>] (warn_slowpath_null+0x1c/0x24) from [<c0018e9c>]
(__arm_ioremap_pfn_caller+0x1d8/0x1f0)
>> [<c0018e9c>] (__arm_ioremap_pfn_caller+0x1d8/0x1f0) from [<c0018f20>]
(__arm_ioremap_caller+0x54/0x5c)
>> [<c0018f20>] (__arm_ioremap_caller+0x54/0x5c) from [<c0018c58>]
(__arm_ioremap+0x18/0x1c)
>> [<c0018c58>] (__arm_ioremap+0x18/0x1c) from [<c00168fc>]
(copy_oldmem_page+0x34/0xc0)
>> [<c00168fc>] (copy_oldmem_page+0x34/0xc0) from [<c010350c>]
(read_from_oldmem+0xb8/0xe4)
>> [<c010350c>] (read_from_oldmem+0xb8/0xe4) from [<c05c37e0>]
(parse_crash_elf32_headers+0x184/0x43c)
>> [<c05c37e0>] (parse_crash_elf32_headers+0x184/0x43c) from [<c05c3b64>]
(vmcore_init+0xcc/0x198)
>> [<c05c3b64>] (vmcore_init+0xcc/0x198) from [<c000863c>]
(do_one_initcall+0x34/0x184)
>> [<c000863c>] (do_one_initcall+0x34/0x184) from [<c05b28dc>]
(kernel_init_freeable+0xfc/0x1c8)
>> [<c05b28dc>] (kernel_init_freeable+0xfc/0x1c8) from [<c04326d4>]
(kernel_init+0x8/0xe4)
>> [<c04326d4>] (kernel_init+0x8/0xe4) from [<c000ec58>]
(ret_from_fork+0x14/0x3c)
>>
>> arch/arm/mm/ioremap.c:244
>>??????? /*
>>????????? * Don't allow RAM to be mapped - this causes problems with
ARMv6+
>>????????? */
>>???????? if (WARN_ON(pfn_valid(pfn)))
>>???????????????? return NULL;

Thanks in advance for any help.

-andy

kdump for ARM Linux?

[Rob Herring]

On Tue, Apr 22, 2014 at 7:18 PM, Andy Nicholas
<andy.nicholas.work@gmail.com> wrote:
> Hello, hopefully this is the correct mailing list for this question:

Yes.

> I'm working on a derivative of the mainline Linux 3.8 kernel and I'm trying
> to enable ARM kdump functionality to collect crashdumps when we have kernel
> problems. But, there's some kind of unresolved issue in
> arch/arm/mm/ioremap.c which prevents /proc/vmcore from being able to
> function properly. I checked and this appears to still be in kernel.org
> Linux 3.13. The target platform is a regular, recent ARMv7 compatible chip.

There are only irregular platforms.

> Has this issue been addressed in any version of an ARM Linux kernel? Or, is
> there a work-around? If not, how does a crashdump file get generated when/if
> the kernel crashes or a driver faults?
>
>>> WARNING: at arch/arm/mm/ioremap.c:244
> __arm_ioremap_pfn_caller+0x1d8/0x1f0()
>>> Modules linked in:
>>> [<c0016660>] (unwind_backtrace+0x0/0x138) from [<c0020480>]
> (warn_slowpath_common+0x4c/0x64)
>>> [<c0020480>] (warn_slowpath_common+0x4c/0x64) from [<c00204b4>]
> (warn_slowpath_null+0x1c/0x24)
>>> [<c00204b4>] (warn_slowpath_null+0x1c/0x24) from [<c0018e9c>]
> (__arm_ioremap_pfn_caller+0x1d8/0x1f0)
>>> [<c0018e9c>] (__arm_ioremap_pfn_caller+0x1d8/0x1f0) from [<c0018f20>]
> (__arm_ioremap_caller+0x54/0x5c)
>>> [<c0018f20>] (__arm_ioremap_caller+0x54/0x5c) from [<c0018c58>]
> (__arm_ioremap+0x18/0x1c)
>>> [<c0018c58>] (__arm_ioremap+0x18/0x1c) from [<c00168fc>]
> (copy_oldmem_page+0x34/0xc0)
>>> [<c00168fc>] (copy_oldmem_page+0x34/0xc0) from [<c010350c>]
> (read_from_oldmem+0xb8/0xe4)
>>> [<c010350c>] (read_from_oldmem+0xb8/0xe4) from [<c05c37e0>]
> (parse_crash_elf32_headers+0x184/0x43c)
>>> [<c05c37e0>] (parse_crash_elf32_headers+0x184/0x43c) from [<c05c3b64>]
> (vmcore_init+0xcc/0x198)
>>> [<c05c3b64>] (vmcore_init+0xcc/0x198) from [<c000863c>]
> (do_one_initcall+0x34/0x184)
>>> [<c000863c>] (do_one_initcall+0x34/0x184) from [<c05b28dc>]
> (kernel_init_freeable+0xfc/0x1c8)
>>> [<c05b28dc>] (kernel_init_freeable+0xfc/0x1c8) from [<c04326d4>]
> (kernel_init+0x8/0xe4)
>>> [<c04326d4>] (kernel_init+0x8/0xe4) from [<c000ec58>]
> (ret_from_fork+0x14/0x3c)
>>>
>>> arch/arm/mm/ioremap.c:244
>>>        /*
>>>          * Don't allow RAM to be mapped - this causes problems with
> ARMv6+
>>>          */
>>>         if (WARN_ON(pfn_valid(pfn)))
>>>                 return NULL;
>
> Thanks in advance for any help.

This is on purpose as the comment says because 2 mappings of different
types (of memory attributes) is undefined behavior on ARMv6+. RAM is
normal memory type and mmio devices are device memory. This check
could possibly be relaxed in the case the memory type is compatible
with normal RAM mappings. Then perhaps ioremap_cache could be used on
RAM for kdump.

Rob

kdump for ARM Linux?

[Rob Herring]

On Wed, Apr 23, 2014 at 11:51 AM, Andrew Nicholas
<andy.nicholas.work@gmail.com> wrote:
>
>
>
> On Tue, Apr 22, 2014 at 6:36 PM, Rob Herring <robherring2@gmail.com> wrote:
>>
>> On Tue, Apr 22, 2014 at 7:18 PM, Andy Nicholas
>> <andy.nicholas.work@gmail.com> wrote:
>
>
>>
>> > Has this issue been addressed in any version of an ARM Linux kernel? Or,
>> > is
>> > there a work-around? If not, how does a crashdump file get generated
>> > when/if
>> > the kernel crashes or a driver faults?
>> >
>> >>> arch/arm/mm/ioremap.c:244
>> >>>        /*
>> >>>          * Don't allow RAM to be mapped - this causes problems with
>> > ARMv6+
>> >>>          */
>> >>>         if (WARN_ON(pfn_valid(pfn)))
>> >>>                 return NULL;
>> >
>> > Thanks in advance for any help.
>>
>> This is on purpose as the comment says because 2 mappings of different
>> types (of memory attributes) is undefined behavior on ARMv6+. RAM is
>> normal memory type and mmio devices are device memory. This check
>> could possibly be relaxed in the case the memory type is compatible
>> with normal RAM mappings. Then perhaps ioremap_cache could be used on
>> RAM for kdump.
>
>
> Thanks. I'm not very familiar with this code-path and looking at the code it
> seems one possibility is that pfn_valid() is returning false due to
> misconfiguration
> of the kernel.
>
> Considering that the -normal- kdump path to create the /proc/vmcore dumpfile
> via
> parse_crash_elf32_headers appears to use __arm_ioremap in order to copy the
> old memory from the old (presumably crashed) kernel -- this means that no
> one
> with an ARMv7 platform has ever gotten a dumpfile via kdump?

Why v7? I don't think kdump would work on any ARM platform since the
pfn_valid check was added. I'm not too surprised as kexec/kdump seem
to be rarely used in practice and frequently broken.

Something like this is what I had in mind. Alternatively, avoiding
ioremap entirely might be a better solution. I think kmap_atomic could
be used instead of ioremap.

diff --git a/arch/arm/kernel/crash_dump.c b/arch/arm/kernel/crash_dump.c
index 5d1286d..1adca4e 100644
--- a/arch/arm/kernel/crash_dump.c
+++ b/arch/arm/kernel/crash_dump.c
@@ -39,7 +39,7 @@ ssize_t copy_oldmem_page(unsigned long pfn, char *buf,
        if (!csize)
                return 0;

-       vaddr = ioremap(__pfn_to_phys(pfn), PAGE_SIZE);
+       vaddr = ioremap_cache(__pfn_to_phys(pfn), PAGE_SIZE);
        if (!vaddr)
                return -ENOMEM;

diff --git a/arch/arm/mm/ioremap.c b/arch/arm/mm/ioremap.c
index f9c32ba..0cd30d6 100644
--- a/arch/arm/mm/ioremap.c
+++ b/arch/arm/mm/ioremap.c
@@ -298,7 +298,7 @@ void __iomem * __arm_ioremap_pfn_caller(unsigned long pfn,
        /*
         * Don't allow RAM to be mapped - this causes problems with ARMv6+
         */
-       if (WARN_ON(pfn_valid(pfn)))
+       if (WARN_ON(pfn_valid(pfn) && mtype != MT_DEVICE_CACHED))
                return NULL;

        area = get_vm_area_caller(size, VM_IOREMAP, caller);