All of lore.kernel.org
 help / color / mirror / Atom feed
From: Guenter Roeck <linux@roeck-us.net>
To: Tobias Klauser <tklauser@distanz.ch>
Cc: Sven Schmidt <4sschmid@informatik.uni-hamburg.de>,
	Sandra Loosemore <sandra@codesourcery.com>,
	Arnd Bergmann <arnd@arndb.de>,
	Andrew Morton <akpm@linux-foundation.org>,
	linux-kernel@vger.kernel.org, Ley Foon Tan <lftan@altera.com>,
	nios2-dev@lists.rocketboards.org
Subject: Re: nios2 crash/hang in mainline due to 'lib: update LZ4 compressor module'
Date: Thu, 9 Mar 2017 10:49:38 -0800	[thread overview]
Message-ID: <20170309184938.GB10719@roeck-us.net> (raw)
In-Reply-To: <20170309144340.GH27998@distanz.ch>

On Thu, Mar 09, 2017 at 03:43:40PM +0100, Tobias Klauser wrote:
> On 2017-03-09 at 14:20:51 +0100, Guenter Roeck <linux@roeck-us.net> wrote:
> > On 03/07/2017 04:46 AM, Tobias Klauser wrote:
> > [ ... ]
> > 
> > >
> > >Linux version 4.11.0-rc1-dirty (tobiask@ziws08) (gcc version 7.0.1 20170226 (experimental) (GCC) ) #46 Tue Mar 7 13:40:53 CET 2017
> > >bootconsole [early0] enabled
> > >Early console on uart16650 initialized at 0xf8001600
> > >OF: fdt: Error -11 processing FDT
> > >Kernel panic - not syncing: setup_cpuinfo: No CPU found in devicetree!
> > >
> > >---[ end Kernel panic - not syncing: setup_cpuinfo: No CPU found in devicetree!
> > >
> > >Looks like the in-memory device tree somehow gets corrupted. Not sure
> > >yet why and how this is linked to the Kconfig options selected but at
> > >least we now have a possibility to use debug messages earlier on.
> > >
> > 
> > I think I found the problem. In unflatten_and_copy_device_tree(), with added
> > debug information:
> > 
> > OF: fdt: initial_boot_params=c861e400, dt=c861f000 size=28874 (0x70ca)
> > 
> > ... and then initial_boot_params is copied to dt, which results in corrupted
> > fdt since the memory overlaps. Looks like the initial_boot_params memory
> > is not reserved and (re-)allocated by early_init_dt_alloc_memory_arch().
> 
> Thanks for the analysis. That certainly explains the issue. The
> following patch solves the issue for me. Though I'm not entirely sure if
> it is correct and that is all that is needed. Do we need to retain the
> memory for initial_boot_params after bootmem is freed?
> 

I don't know if it is correct either, but it matches what I came up with,
and it does work for me as well. Feel free to add

Tested-by: Guenter Roeck <linux@roeck-us.net>

when you submit the patch for real.

Thanks,
Guenter

> diff --git a/arch/nios2/kernel/prom.c b/arch/nios2/kernel/prom.c
> index 099f5ce1f3cb..6869fe03f3ff 100644
> --- a/arch/nios2/kernel/prom.c
> +++ b/arch/nios2/kernel/prom.c
> @@ -48,6 +48,13 @@ void * __init early_init_dt_alloc_memory_arch(u64 size, u64 align)
>  	return alloc_bootmem_align(size, align);
>  }
>  
> +int __init early_init_dt_reserve_memory_arch(phys_addr_t base,
> +					phys_addr_t size, bool nomap)
> +{
> +	reserve_bootmem(base, size, BOOTMEM_DEFAULT);
> +	return 0;
> +}
> +
>  void __init early_init_devtree(void *params)
>  {
>  	__be32 *dtb = (u32 *)__dtb_start;
> diff --git a/arch/nios2/kernel/setup.c b/arch/nios2/kernel/setup.c
> index 6e57ffa5db27..6044d9be28b4 100644
> --- a/arch/nios2/kernel/setup.c
> +++ b/arch/nios2/kernel/setup.c
> @@ -201,6 +201,9 @@ void __init setup_arch(char **cmdline_p)
>  	}
>  #endif /* CONFIG_BLK_DEV_INITRD */
>  
> +	early_init_fdt_reserve_self();
> +	early_init_fdt_scan_reserved_mem();
> +
>  	unflatten_and_copy_device_tree();
>  
>  	setup_cpuinfo();

  reply	other threads:[~2017-03-09 20:09 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-02-26 21:03 nios2 crash/hang in mainline due to 'lib: update LZ4 compressor module' Guenter Roeck
2017-02-27 19:34 ` Sven Schmidt
2017-02-27 20:37   ` Guenter Roeck
2017-02-28 15:53 ` Tobias Klauser
2017-02-28 17:53   ` Sandra Loosemore
2017-02-28 18:14     ` Guenter Roeck
2017-03-01 18:58       ` Sven Schmidt
2017-03-01 19:45         ` Guenter Roeck
2017-03-02 16:38           ` Tobias Klauser
2017-03-03  3:04             ` Guenter Roeck
2017-03-07 12:46               ` Tobias Klauser
2017-03-08  4:12                 ` Guenter Roeck
2017-03-09 13:20                 ` Guenter Roeck
2017-03-09 14:43                   ` Tobias Klauser
2017-03-09 18:49                     ` Guenter Roeck [this message]
2017-03-01 22:50         ` Sandra Loosemore
2017-03-02 13:30           ` Tobias Klauser
2017-02-28 17:57   ` Guenter Roeck

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=20170309184938.GB10719@roeck-us.net \
    --to=linux@roeck-us.net \
    --cc=4sschmid@informatik.uni-hamburg.de \
    --cc=akpm@linux-foundation.org \
    --cc=arnd@arndb.de \
    --cc=lftan@altera.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=nios2-dev@lists.rocketboards.org \
    --cc=sandra@codesourcery.com \
    --cc=tklauser@distanz.ch \
    /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.