On Wed, Jun 19, 2019 at 09:39:40AM +0200, Geert Uytterhoeven wrote:
> Hi Mike,
>
> On Wed, Jun 19, 2019 at 9:06 AM Geert Uytterhoeven <ge...@linux-m68k.org>
> wrote:
> > On Tue, Jun 18, 2019 at 8:10 AM Mike Rapoport <r...@linux.ibm.com> wrote:
> > > On Mon, Jun 17, 2019 at 10:00:32PM +0200, Geert Uytterhoeven wrote:
> > > > On Thu, May 16, 2019 at 8:03 AM Mike Rapoport <r...@linux.ibm.com>
> > > > wrote:
> > > > > These pacthes replace DISCONTIGMEM with SPARSEMEM on m68k for systems
> > > > > with
> > > > > !SINGLE_MEMORY_CHUNK set.
> > > > >
> > > > > With SPARSEMEM there is a single node for the entire physical memory
> > > > > and to
> > > > > cope with holes in the physical address space it is divided to
> > > > > sections of
> > > > > up to 16M.
> > > > >
> > > > > Each section has it's own memory map which size depends on actual
> > > > > populated
> > > > > memory.
> > > > >
> > > > > The section size of 16M was chosen pretty much arbitrarily as I
> > > > > couldn't
> > > > > find specs for systems with e.g. Zorro memory extensions.
> >
> > > > Unfortunately it crashes on my Amiga, cfr. the logs below.
> > > >
> > > > Then I realized the "section size of 16M". My Amiga has a single block
> > > > of 12 MiB of FastRAM at 0x07400000, which is not aligned to 16 MiB.
> > > > (Yes, base address of motherboard RAM is 0x08000000 - ramsize ;-)
> > > >
> > > > I've tried:
> > > >
> > > > -#define MAX_PHYSMEM_BITS 32
> > > > -#define SECTION_SIZE_BITS 24
> > > > +#define MAX_PHYSMEM_BITS 30
> > > > +#define SECTION_SIZE_BITS 22
> > > >
> > > > but that doesn't seem to make a difference.
> > > >
> > > > Do you have a clue? Thanks!
> > >
> > > Not really, at least yet.
> > > Can you please send the entire log with
> > >
> > > "mminit_loglevel=4 memblock=debug debug"
> > >
> > > in the command line?
> >
> > Attached, with debug_boot_weak_hash added, which reveals it's a real
> > NULL (=0x0) pointer dereference.
> >
> > Looking at the disassembly, it happens in clear_page().
> > Call chain:
> >
> > get_page_from_freelist()
> > prep_new_page()
> > clear_highpage()
> > void *kaddr = kmap_atomic(page);
> > clear_page(kaddr);
> >
> > get_page_from_freelist() verifies page is non-zero before calling
> > prep_new_page(), so it must be the kmap_atomic() that returns NULL.
> >
> > kmap_atomic() basically does page_address(page).
> > As m68k defines WANT_PAGE_VIRTUAL, that evaluates to page->virtual,
> > which I assume to be NULL.
> > Is there a call to set_page_address() missing in the sparsemem code?
> >
> > Questions:
> > 1. Why does it work on Atari/ARAnyM?
> > 2. Why does it work on SPARC64, which also uses WANT_PAGE_VIRTUAL
> > and has SPARSEMEM support? (arc uses WANT_PAGE_VIRTUAL, but no
> > SPARSEMEM)
>
> Oh, I have CONFIG_SINGLE_MEMORY_CHUNK=y, so SPARSEMEM is
> _not_ used.
Well, that means I've managed to break FLATMEM :)
My guess would be that pfn_to_page()/page_to_pfn() are wrong with memory
starting at !0 address.
Can you please try the patch below to see if this helps with your machine?
If yes, I'll think of a proper way to fix the pfn <-> page conversion.
diff --git a/arch/m68k/include/asm/page_mm.h b/arch/m68k/include/asm/page_mm.h
index 2fa176b1e583..25e300413e0f 100644
--- a/arch/m68k/include/asm/page_mm.h
+++ b/arch/m68k/include/asm/page_mm.h
@@ -167,6 +167,7 @@ static inline __attribute_const__ int
__virt_to_node_shift(void)
((__p) - pgdat->node_mem_map) + pgdat->node_start_pfn; \
})
#else
+#define ARCH_PFN_OFFSET (0x07400000 >> PAGE_SHIFT)
#include <asm-generic/memory_model.h>
#endif
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 --
> ge...@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
--
Sincerely yours,
Mike.
