All of lore.kernel.org
 help / color / mirror / Atom feed
From: Geert Uytterhoeven <geert@linux-m68k.org>
To: linux-arm-kernel@lists.infradead.org
Subject: Re: BUG: Bad page state in process swapper pfn:00000
Date: Wed, 11 Jun 2014 19:19:10 +0000	[thread overview]
Message-ID: <CAMuHMdWZutiNpGScEhCzgM70jJ+MZ1ErmKtNfMHVLDB+d5Lyzw@mail.gmail.com> (raw)
In-Reply-To: <539892BD.8020403@codeaurora.org>

Hi Laura,

On Wed, Jun 11, 2014 at 7:32 PM, Laura Abbott <lauraa@codeaurora.org> wrote:
> On 6/11/2014 4:40 AM, Geert Uytterhoeven wrote:
>> With current mainline, I get an early crash on r8a7791/koelsch:
>>
>> BUG: Bad page state in process swapper  pfn:00000
>> page:ee20b000 count:0 mapcount:0 mapping:66756200 index:0x65726566
>> page flags: 0x74656b63(locked|error|lru|active|owner_priv_1|arch_1|private|writeback|head|swapcache
>> |reclaim|mlocked)
>> page dumped because: PAGE_FLAGS_CHECK_AT_FREE flag(s) set
>> bad because of flags:
>> page flags: 0x212861(locked|lru|active|private|writeback|swapcache|mlocked)
>>
>> I bisected it to
>>
>> commit 1c2f87c22566cd057bc8cde10c37ae9da1a1bb76
>> Author: Laura Abbott <lauraa@codeaurora.org>
>> Date:   Sun Apr 13 22:54:58 2014 +0100
>>
>>     ARM: 8025/1: Get rid of meminfo

>> -Truncating RAM at 40000000-bfffffff to -6f7fffff (vmalloc region overlap).
>> +Truncating RAM at 0x00000000-0xc0000000 to -0x6f800000
>
> I'm guessing this is the issue right there.
>
>         memory@40000000 {
>                 device_type = "memory";
>                 reg = <0 0x40000000 0 0x40000000>;
>         };
>
>         memory@200000000 {
>                 device_type = "memory";
>                 reg = <2 0x00000000 0 0x40000000>;
>         };
>
> Those are the memory nodes from r8a7791-koelsch.dts. It looks like the memory
> outside 32-bit address range is not being dropped. It was suggested to drop
> early_init_dt_add_memory_arch which called arm_add_memory and just use the
> generic of code directly but the problem is arm_add_memory does additional
> bounds checking. It looks like early_init_dt_add_memory_arch in
> drivers/of/fdt.c checks for overflow on u64 types but not for overflow
> on phys_addr_t (32 bits) which is what memblock_add actually uses.
>
> For a quick test, can you try bringing back early_init_dt_add_memory_arch
> and see if that fixes the problem:
>
> diff --git a/arch/arm/kernel/devtree.c b/arch/arm/kernel/devtree.c
> index e94a157..ea9ce92 100644
> --- a/arch/arm/kernel/devtree.c
> +++ b/arch/arm/kernel/devtree.c
> @@ -27,6 +27,10 @@
>  #include <asm/mach/arch.h>
>  #include <asm/mach-types.h>
>
> +void __init early_init_dt_add_memory_arch(u64 base, u64 size)
> +{
> +       arm_add_memory(base, size);
> +}
>
>  #ifdef CONFIG_SMP
>  extern struct of_cpu_method __cpu_method_of_table[];

Thanks, my board boots again after applying this quick hack.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

WARNING: multiple messages have this Message-ID (diff)
From: Geert Uytterhoeven <geert@linux-m68k.org>
To: Laura Abbott <lauraa@codeaurora.org>
Cc: Russell King <rmk+kernel@arm.linux.org.uk>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-arm-kernel@lists.infradead.org" 
	<linux-arm-kernel@lists.infradead.org>,
	Linux-sh list <linux-sh@vger.kernel.org>,
	Grant Likely <grant.likely@linaro.org>
Subject: Re: BUG: Bad page state in process swapper pfn:00000
Date: Wed, 11 Jun 2014 21:19:10 +0200	[thread overview]
Message-ID: <CAMuHMdWZutiNpGScEhCzgM70jJ+MZ1ErmKtNfMHVLDB+d5Lyzw@mail.gmail.com> (raw)
In-Reply-To: <539892BD.8020403@codeaurora.org>

Hi Laura,

On Wed, Jun 11, 2014 at 7:32 PM, Laura Abbott <lauraa@codeaurora.org> wrote:
> On 6/11/2014 4:40 AM, Geert Uytterhoeven wrote:
>> With current mainline, I get an early crash on r8a7791/koelsch:
>>
>> BUG: Bad page state in process swapper  pfn:00000
>> page:ee20b000 count:0 mapcount:0 mapping:66756200 index:0x65726566
>> page flags: 0x74656b63(locked|error|lru|active|owner_priv_1|arch_1|private|writeback|head|swapcache
>> |reclaim|mlocked)
>> page dumped because: PAGE_FLAGS_CHECK_AT_FREE flag(s) set
>> bad because of flags:
>> page flags: 0x212861(locked|lru|active|private|writeback|swapcache|mlocked)
>>
>> I bisected it to
>>
>> commit 1c2f87c22566cd057bc8cde10c37ae9da1a1bb76
>> Author: Laura Abbott <lauraa@codeaurora.org>
>> Date:   Sun Apr 13 22:54:58 2014 +0100
>>
>>     ARM: 8025/1: Get rid of meminfo

>> -Truncating RAM at 40000000-bfffffff to -6f7fffff (vmalloc region overlap).
>> +Truncating RAM at 0x00000000-0xc0000000 to -0x6f800000
>
> I'm guessing this is the issue right there.
>
>         memory@40000000 {
>                 device_type = "memory";
>                 reg = <0 0x40000000 0 0x40000000>;
>         };
>
>         memory@200000000 {
>                 device_type = "memory";
>                 reg = <2 0x00000000 0 0x40000000>;
>         };
>
> Those are the memory nodes from r8a7791-koelsch.dts. It looks like the memory
> outside 32-bit address range is not being dropped. It was suggested to drop
> early_init_dt_add_memory_arch which called arm_add_memory and just use the
> generic of code directly but the problem is arm_add_memory does additional
> bounds checking. It looks like early_init_dt_add_memory_arch in
> drivers/of/fdt.c checks for overflow on u64 types but not for overflow
> on phys_addr_t (32 bits) which is what memblock_add actually uses.
>
> For a quick test, can you try bringing back early_init_dt_add_memory_arch
> and see if that fixes the problem:
>
> diff --git a/arch/arm/kernel/devtree.c b/arch/arm/kernel/devtree.c
> index e94a157..ea9ce92 100644
> --- a/arch/arm/kernel/devtree.c
> +++ b/arch/arm/kernel/devtree.c
> @@ -27,6 +27,10 @@
>  #include <asm/mach/arch.h>
>  #include <asm/mach-types.h>
>
> +void __init early_init_dt_add_memory_arch(u64 base, u64 size)
> +{
> +       arm_add_memory(base, size);
> +}
>
>  #ifdef CONFIG_SMP
>  extern struct of_cpu_method __cpu_method_of_table[];

Thanks, my board boots again after applying this quick hack.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

WARNING: multiple messages have this Message-ID (diff)
From: geert@linux-m68k.org (Geert Uytterhoeven)
To: linux-arm-kernel@lists.infradead.org
Subject: BUG: Bad page state in process swapper pfn:00000
Date: Wed, 11 Jun 2014 21:19:10 +0200	[thread overview]
Message-ID: <CAMuHMdWZutiNpGScEhCzgM70jJ+MZ1ErmKtNfMHVLDB+d5Lyzw@mail.gmail.com> (raw)
In-Reply-To: <539892BD.8020403@codeaurora.org>

Hi Laura,

On Wed, Jun 11, 2014 at 7:32 PM, Laura Abbott <lauraa@codeaurora.org> wrote:
> On 6/11/2014 4:40 AM, Geert Uytterhoeven wrote:
>> With current mainline, I get an early crash on r8a7791/koelsch:
>>
>> BUG: Bad page state in process swapper  pfn:00000
>> page:ee20b000 count:0 mapcount:0 mapping:66756200 index:0x65726566
>> page flags: 0x74656b63(locked|error|lru|active|owner_priv_1|arch_1|private|writeback|head|swapcache
>> |reclaim|mlocked)
>> page dumped because: PAGE_FLAGS_CHECK_AT_FREE flag(s) set
>> bad because of flags:
>> page flags: 0x212861(locked|lru|active|private|writeback|swapcache|mlocked)
>>
>> I bisected it to
>>
>> commit 1c2f87c22566cd057bc8cde10c37ae9da1a1bb76
>> Author: Laura Abbott <lauraa@codeaurora.org>
>> Date:   Sun Apr 13 22:54:58 2014 +0100
>>
>>     ARM: 8025/1: Get rid of meminfo

>> -Truncating RAM at 40000000-bfffffff to -6f7fffff (vmalloc region overlap).
>> +Truncating RAM at 0x00000000-0xc0000000 to -0x6f800000
>
> I'm guessing this is the issue right there.
>
>         memory at 40000000 {
>                 device_type = "memory";
>                 reg = <0 0x40000000 0 0x40000000>;
>         };
>
>         memory at 200000000 {
>                 device_type = "memory";
>                 reg = <2 0x00000000 0 0x40000000>;
>         };
>
> Those are the memory nodes from r8a7791-koelsch.dts. It looks like the memory
> outside 32-bit address range is not being dropped. It was suggested to drop
> early_init_dt_add_memory_arch which called arm_add_memory and just use the
> generic of code directly but the problem is arm_add_memory does additional
> bounds checking. It looks like early_init_dt_add_memory_arch in
> drivers/of/fdt.c checks for overflow on u64 types but not for overflow
> on phys_addr_t (32 bits) which is what memblock_add actually uses.
>
> For a quick test, can you try bringing back early_init_dt_add_memory_arch
> and see if that fixes the problem:
>
> diff --git a/arch/arm/kernel/devtree.c b/arch/arm/kernel/devtree.c
> index e94a157..ea9ce92 100644
> --- a/arch/arm/kernel/devtree.c
> +++ b/arch/arm/kernel/devtree.c
> @@ -27,6 +27,10 @@
>  #include <asm/mach/arch.h>
>  #include <asm/mach-types.h>
>
> +void __init early_init_dt_add_memory_arch(u64 base, u64 size)
> +{
> +       arm_add_memory(base, size);
> +}
>
>  #ifdef CONFIG_SMP
>  extern struct of_cpu_method __cpu_method_of_table[];

Thanks, my board boots again after applying this quick hack.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

  reply	other threads:[~2014-06-11 19:19 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-06-11 11:40 BUG: Bad page state in process swapper pfn:00000 Geert Uytterhoeven
2014-06-11 11:40 ` Geert Uytterhoeven
2014-06-11 11:40 ` Geert Uytterhoeven
2014-06-11 17:32 ` Laura Abbott
2014-06-11 17:32   ` Laura Abbott
2014-06-11 17:32   ` Laura Abbott
2014-06-11 19:19   ` Geert Uytterhoeven [this message]
2014-06-11 19:19     ` Geert Uytterhoeven
2014-06-11 19:19     ` Geert Uytterhoeven
2014-06-12  2:51     ` Laura Abbott
2014-06-12  2:51       ` Laura Abbott
2014-06-12  2:51       ` Laura Abbott
2014-06-16  8:35       ` Geert Uytterhoeven
2014-06-16  8:35         ` Geert Uytterhoeven
2014-06-16  8:35         ` Geert Uytterhoeven
2014-06-17 12:40       ` Grant Likely
2014-06-17 12:40         ` Grant Likely
2014-06-17 12:40         ` Grant Likely

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAMuHMdWZutiNpGScEhCzgM70jJ+MZ1ErmKtNfMHVLDB+d5Lyzw@mail.gmail.com \
    --to=geert@linux-m68k.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.