Re: [PATCH v2 0/3] m68k/mm: switch from DISCONTIGMEM to SPARSEMEM

[Geert Uytterhoeven <geert@xxxxxxxxxxxxxx>]

Hi Mike,

On Sun, Jun 30, 2019 at 10:58 AM Mike Rapoport <rppt@xxxxxxxxxxxxx> wrote:
> On Sun, Jun 30, 2019 at 12:54:49PM +1200, Michael Schmitz wrote:
> > Am 29.06.2019 um 23:30 schrieb Mike Rapoport:
> > > On Thu, Jun 20, 2019 at 06:46:28PM +0200, Geert Uytterhoeven wrote:
> > > > On Wed, Jun 19, 2019 at 4:18 PM Mike Rapoport <rppt@xxxxxxxxxxxxx> wrote:
> > > > > On Wed, Jun 19, 2019 at 09:39:40AM +0200, Geert Uytterhoeven wrote:
> > > > > > On Wed, Jun 19, 2019 at 9:06 AM Geert Uytterhoeven <geert@xxxxxxxxxxxxxx> wrote:
> > > > > > > On Tue, Jun 18, 2019 at 8:10 AM Mike Rapoport <rppt@xxxxxxxxxxxxx> wrote:
> > > >
> > > > Thanks, that hack did fix CONFIG_SINGLE_MEMORY_CHUNK=y.
> > > >
> > > > Back to sparsemem...
> > > >
> > > > With CONFIG_SINGLE_MEMORY_CHUNK=n, and CONFIG_SPARSEMEM=y,
> > > > it also fails.  Diff between working single memory chunk and failing
> > > > sparsemem:
> > > >
> > > >   -Memory: 7796K/12288K available (2555K kernel code, 259K rwdata,
> > > > 700K rodata, 136K init, 153K bss, 4492K reserved, 0K cma-reserved)
> > > >   +Memory: 7816K/131072K available (2556K kernel code, 261K rwdata,
> > > > 700K rodata, 136K init, 157K bss, 123256K reserved, 0K cma-reserved)
> > > >
> > > > Oops, looks like it thinks there's memory from 0x00000000-0x08000000,
> > > > instead of 0x07400000-0x08000000.
> > >
> > > Yeah, I've made a mistake in the zone/hole size calculations as it seems.
> > >
> > > Can you try this:
> > >
> > > diff --git a/arch/m68k/mm/motorola.c b/arch/m68k/mm/motorola.c
> > > index 87d09942be5c..bf438a0da173 100644
> > > --- a/arch/m68k/mm/motorola.c
> > > +++ b/arch/m68k/mm/motorola.c
> > > @@ -229,10 +229,8 @@ static void m68k_free_area_init(unsigned long max_addr)
> > >     memblock_set_bottom_up(true);
> > >
> > >     zones_size[ZONE_DMA] = max_addr >> PAGE_SHIFT;
> > > -    if (m68k_num_memory > 1) {
> > > -            holes_size = max_addr - memblock_phys_mem_size();
> > > -            zholes_size[ZONE_DMA] = holes_size >> PAGE_SHIFT;
> > > -    }
> > > +    holes_size = max_addr - memblock_phys_mem_size();
> > > +    zholes_size[ZONE_DMA] =  >> PAGE_SHIFT;
> >
> > gcc fails to parse that line. Lost a holes_size, perhaps?
>
> Oops, indeed.

Thanks, we're getting progress.  My system is booting again from hard drive
with CONFIG_SINGLE_MEMORY_CHUNK=n.
When booting from an initrd, it still crashes, see attached dmesg.

Hence still to fix:
  1. Proper solution for CONFIG_SINGLE_MEMORY_CHUNK=y,
  2. CONFIG_SINGLE_MEMORY_CHUNK=n and initrd.

Thanks!

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@xxxxxxxxxxxxxx

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

Attachment: dmesg-5.2.0-rc7-amiga-nomod-01406-g31291cf69a083d9f.1
Description: Binary data