On Mon, Jul 01, 2019 at 01:56:25PM +0200, Geert Uytterhoeven wrote:
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.
The initrd memory is reserved after the memmap is allocated and the initrd
gets overwritten. Can you try this hack please:
diff --git a/arch/m68k/kernel/setup_mm.c b/arch/m68k/kernel/setup_mm.c
index 528484feff80..eea111f25c3a 100644
--- a/arch/m68k/kernel/setup_mm.c
+++ b/arch/m68k/kernel/setup_mm.c
@@ -346,6 +346,13 @@ void __init setup_arch(char **cmdline_p)
panic("No configuration setup");
}
+#ifndef CONFIG_SUN3
+#ifdef CONFIG_BLK_DEV_INITRD
+ if (m68k_ramdisk.size)
+ memblock_reserve(m68k_ramdisk.addr, m68k_ramdisk.size);
+#endif
+#endif
+
paging_init();
#ifdef CONFIG_NATFEAT
@@ -355,7 +362,6 @@ void __init setup_arch(char **cmdline_p)
#ifndef CONFIG_SUN3
#ifdef CONFIG_BLK_DEV_INITRD
if (m68k_ramdisk.size) {
- memblock_reserve(m68k_ramdisk.addr, m68k_ramdisk.size);
initrd_start = (unsigned long)phys_to_virt(m68k_ramdisk.addr);
initrd_end = initrd_start + m68k_ramdisk.size;
pr_info("initrd: %08lx - %08lx\n", initrd_start, initrd_end);
Hence still to fix:
1. Proper solution for CONFIG_SINGLE_MEMORY_CHUNK=y,
2. CONFIG_SINGLE_MEMORY_CHUNK=n and initrd.
Even with those fixes I'm still concerned about the SECTION_SIZE_BITS and
MAX_PHYSMEM_BITS definitions.
Without implementing vmemmap support we are limited in their maximal
difference by 8 bits. That means that either minimal section size would be
16M or the maximal physical memory size would be limited to 1G. I'm not
that familiar with m68k machine variants to say if either of these
assumptions can be used.
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
--
Sincerely yours,
Mike.
