On Mon, Sep 16, 2019 at 12:52:35PM +0300, Mike Rapoport wrote:
> On Mon, Sep 16, 2019 at 11:07:05AM +0200, Thomas Bogendoerfer wrote:
> > Patch is good. I've compared bootlogs and output is the same
> > regarding memblock/memory debug messages.
>
> Can I add your co-developed+signed-off then?
yes
On Mon, Sep 16, 2019 at 11:07:05AM +0200, Thomas Bogendoerfer wrote:
> On Sat, Sep 14, 2019 at 11:41:13AM +0100, Mike Rapoport wrote:
> > On Thu, Sep 12, 2019 at 04:09:12PM +0200, Thomas Bogendoerfer wrote:
> > > On Thu, Sep 12, 2019 at 03:55:39PM +0200, Thomas Bogendoerfer wrote:
> > > > - reserve
On Sat, Sep 14, 2019 at 11:41:13AM +0100, Mike Rapoport wrote:
> On Thu, Sep 12, 2019 at 04:09:12PM +0200, Thomas Bogendoerfer wrote:
> > On Thu, Sep 12, 2019 at 03:55:39PM +0200, Thomas Bogendoerfer wrote:
> > > - reserved[0xd] [0x00035bff8000-0x00035bff],
> > > 0x8000 b
Hi Thomas,
On Thu, Sep 12, 2019 at 04:09:12PM +0200, Thomas Bogendoerfer wrote:
> On Thu, Sep 12, 2019 at 03:55:39PM +0200, Thomas Bogendoerfer wrote:
> > - reserved[0xd] [0x00035bff8000-0x00035bff],
> > 0x8000 bytes flags: 0x0
> >
> > I have no idea which reservation
On September 12, 2019 3:09:12 PM GMT+01:00, Thomas Bogendoerfer
wrote:
>On Thu, Sep 12, 2019 at 03:55:39PM +0200, Thomas Bogendoerfer wrote:
>> - reserved[0xd] [0x00035bff8000-0x00035bff],
>0x8000 bytes flags: 0x0
>>
>> I have no idea which reservation this is, but i
On Thu, Sep 12, 2019 at 03:55:39PM +0200, Thomas Bogendoerfer wrote:
> - reserved[0xd] [0x00035bff8000-0x00035bff],
> 0x8000 bytes flags: 0x0
>
> I have no idea which reservation this is, but it's not from one of the
> node data.
that's sparsemem's mem_section. And
On Thu, 12 Sep 2019 11:58:33 +0100
Mike Rapoport wrote:
> On Wed, Sep 11, 2019 at 04:09:39PM +0200, Thomas Bogendoerfer wrote:
> > Does memblocks_present() deal better with the one reserved page per node
> > than sparse_memory_present_with_active_regions() ? Or is there a better
> > explanation ?
On Wed, Sep 11, 2019 at 04:09:39PM +0200, Thomas Bogendoerfer wrote:
> On Tue, 10 Sep 2019 12:32:44 +0100
> Mike Rapoport wrote:
>
> > [..]
>
> Patch below works on the same Origin.
>
> Does memblocks_present() deal better with the one reserved page per node
> than sparse_memory_present_with_ac
On September 11, 2019 3:09:39 PM GMT+01:00, Thomas Bogendoerfer
wrote:
>On Tue, 10 Sep 2019 12:32:44 +0100
>Mike Rapoport wrote:
>
>> [..]
>
>Patch below works on the same Origin.
>
>Does memblocks_present() deal better with the one reserved page per
>node
>than sparse_memory_present_with_active
On Tue, 10 Sep 2019 12:32:44 +0100
Mike Rapoport wrote:
> [..]
Patch below works on the same Origin.
Does memblocks_present() deal better with the one reserved page per node
than sparse_memory_present_with_active_regions() ? Or is there a better
explanation ? My debug prints didn't make sense o
On Tue, 10 Sep 2019 12:32:44 +0100
Mike Rapoport wrote:
> Before we start adding printks, can you please run with
> CONFIG_DEBUG_MEMORY_INIT=y and with
>
> mminit_loglevel=4 ignore_loglevel
>
> in the command line?
here we go:
Linux version 5.3.0-rc5-01209-g6ba2d3aed465 (tbogendoerfer@samwei
On Mon, Sep 09, 2019 at 06:22:42PM +0200, Thomas Bogendoerfer wrote:
> On Fri, 6 Sep 2019 16:02:24 +0300
> Mike Rapoport wrote:
>
> > I suspect that unaligned access comes from __page_to_pfn, can you please
> > check what scripts/fadd2line reports for kernel_init_free_pages+0xcc/0x138?
>
> kerne
On Fri, 6 Sep 2019 16:02:24 +0300
Mike Rapoport wrote:
> I suspect that unaligned access comes from __page_to_pfn, can you please
> check what scripts/fadd2line reports for kernel_init_free_pages+0xcc/0x138?
kernel_init_free_pages+0xcc/0x138:
pagefault_disabled_dec at include/linux/uaccess.h:173
On Thu, Sep 05, 2019 at 11:38:00PM +0200, Thomas Bogendoerfer wrote:
> On Thu, 5 Sep 2019 18:47:49 +0300
> Mike Rapoport wrote:
>
> > On Thu, Sep 05, 2019 at 03:48:31PM +0200, Thomas Bogendoerfer wrote:
> > > On Thu, 5 Sep 2019 16:32:53 +0300
> > > Mike Rapoport wrote:
> > >
> > > > On Thu, Sep
On Thu, 5 Sep 2019 18:47:49 +0300
Mike Rapoport wrote:
> On Thu, Sep 05, 2019 at 03:48:31PM +0200, Thomas Bogendoerfer wrote:
> > On Thu, 5 Sep 2019 16:32:53 +0300
> > Mike Rapoport wrote:
> >
> > > On Thu, Sep 05, 2019 at 03:21:50PM +0200, Thomas Bogendoerfer wrote:
> > > > On Thu, 5 Sep 2019
On Thu, Sep 05, 2019 at 03:48:31PM +0200, Thomas Bogendoerfer wrote:
> On Thu, 5 Sep 2019 16:32:53 +0300
> Mike Rapoport wrote:
>
> > On Thu, Sep 05, 2019 at 03:21:50PM +0200, Thomas Bogendoerfer wrote:
> > > On Thu, 5 Sep 2019 08:47:57 +0300
> > > Mike Rapoport wrote:
> > >
> > > > From: Mike
On Thu, 5 Sep 2019 16:32:53 +0300
Mike Rapoport wrote:
> On Thu, Sep 05, 2019 at 03:21:50PM +0200, Thomas Bogendoerfer wrote:
> > On Thu, 5 Sep 2019 08:47:57 +0300
> > Mike Rapoport wrote:
> >
> > > From: Mike Rapoport
> > >
> > > The memory initialization of SGI-IP27 is already half-way to
On Thu, Sep 05, 2019 at 03:21:50PM +0200, Thomas Bogendoerfer wrote:
> On Thu, 5 Sep 2019 08:47:57 +0300
> Mike Rapoport wrote:
>
> > From: Mike Rapoport
> >
> > The memory initialization of SGI-IP27 is already half-way to support
> > SPARSEMEM and only a call to sparse_init() was missing. Add
On Thu, 5 Sep 2019 08:47:57 +0300
Mike Rapoport wrote:
> From: Mike Rapoport
>
> The memory initialization of SGI-IP27 is already half-way to support
> SPARSEMEM and only a call to sparse_init() was missing. Add it to
> prom_meminit() and adjust arch/mips/Kconfig to enable SPARSEMEM and
> SPAR
19 matches
Mail list logo
