Re: HIGHMEM freeing patch breaks Realtek RTL930x builds

Re: HIGHMEM freeing patch breaks Realtek RTL930x builds

[markus.stockhausen]

Hi Mike, 

> Von: Mike Rapoport <rppt@kernel.org> 
> Gesendet: Sonntag, 28. Dezember 2025 10:54
> Betreff: Re: HIGHMEM freeing patch breaks Realtek RTL930x builds
> 
> Hi Markus,
>
> On Sat, Dec 20, 2025 at 09:57:40AM +0100, markus.stockhausen@gmx.de wrote:
> > Hi,
> > 
> > sorry for being late on this topic but downstream OpenWrt just started
> > kernel
> > conversion from 6.12 to 6.18 these days. During preparation of the PR
> > https://github.com/openwrt/openwrt/pull/21181 we noticed that Realtek 
> > RTL930x soc based devices with more than 256MB (highmem) do not boot 
> > any longer. 
> > 
> > These are MIPS 34k 32bit multithreaded SoC with layout 
> > <0x00000000 0x10000000>, /* 256 MiB lowmem */
> > <0x20000000 0x10000000>; /* 256 MiB highmem */
> > 
> > Bisecting the issue gave " arch, mm: streamline HIGHMEM freeing" 
> >
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/
> > ?h=v6.15-rc1&id=6faea3422e3b4e8de44a55aa3e6e843320da66d2
> > as the first bad commit. This is back from the 6.15 times.
> > 
> > I have no real idea why removing mem_init_free_highmem() and letting
> > __free_memory_core() work on the whole memory range gives issues.
> > 
> > We are aligning to upstream very slowly and are still in need of 
> > downstream patches so here some additional info.
> > 
> > - Until now we never cared about FLATMEM/SPARSEMEM configs
> > 
> > - We are still using dedicated prom.c/setup.c for the devices
> > https://git.openwrt.org/?p=openwrt/openwrt.git;a=tree;f=target/linux/
> > realtek/files-6.12/arch/mips/rtl838x;hb=HEAD
> > 
> > Any idea or hint is appreciated.
>
> Can you please send logs from a working kernel and a failing kernel with
> "memblock=debug" added to the kernel command line?

Good hint. I've done that and collected all information in
https://github.com/openwrt/openwrt/issues/21323

> Another thing I think worth checking is will the system boot with a
partial
> revert of 6faea3422e3b ("arch, mm: streamline HIGHMEM freeing") for mips:

Will try this out next, update the issue and inform you here.

Thank you

Markus

Re: HIGHMEM freeing patch breaks Realtek RTL930x builds

[Mike Rapoport]

On Mon, Dec 29, 2025 at 07:36:52PM +0100, markus.stockhausen@gmx.de wrote:
> Hi Mike, 
> 
> > Von: Mike Rapoport <rppt@kernel.org> 
> > Gesendet: Sonntag, 28. Dezember 2025 10:54
> > Betreff: Re: HIGHMEM freeing patch breaks Realtek RTL930x builds
> > 
> > Hi Markus,
> >
> > On Sat, Dec 20, 2025 at 09:57:40AM +0100, markus.stockhausen@gmx.de wrote:
> > > Hi,
> > > 
> > > sorry for being late on this topic but downstream OpenWrt just started
> > > kernel
> > > conversion from 6.12 to 6.18 these days. During preparation of the PR
> > > https://github.com/openwrt/openwrt/pull/21181 we noticed that Realtek 
> > > RTL930x soc based devices with more than 256MB (highmem) do not boot 
> > > any longer. 
> > > 
> > > These are MIPS 34k 32bit multithreaded SoC with layout 
> > > <0x00000000 0x10000000>, /* 256 MiB lowmem */
> > > <0x20000000 0x10000000>; /* 256 MiB highmem */
> > > 
> > > Bisecting the issue gave " arch, mm: streamline HIGHMEM freeing" 
> > >
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/
> > > ?h=v6.15-rc1&id=6faea3422e3b4e8de44a55aa3e6e843320da66d2
> > > as the first bad commit. This is back from the 6.15 times.
> > > 
> > > I have no real idea why removing mem_init_free_highmem() and letting
> > > __free_memory_core() work on the whole memory range gives issues.
> > > 
> > > We are aligning to upstream very slowly and are still in need of 
> > > downstream patches so here some additional info.
> > > 
> > > - Until now we never cared about FLATMEM/SPARSEMEM configs
> > > 
> > > - We are still using dedicated prom.c/setup.c for the devices
> > > https://git.openwrt.org/?p=openwrt/openwrt.git;a=tree;f=target/linux/
> > > realtek/files-6.12/arch/mips/rtl838x;hb=HEAD
> > > 
> > > Any idea or hint is appreciated.
> >
> > Can you please send logs from a working kernel and a failing kernel with
> > "memblock=debug" added to the kernel command line?
> 
> Good hint. I've done that and collected all information in
> https://github.com/openwrt/openwrt/issues/21323

The successful boot disables highmem:
[    0.332305] Memory: 495640K/524288K available (8188K kernel code, 647K rwdata, 1504K rodata, 9620K init, 244K bss, 27528K reserved, 0K cma-reserved, 0K highmem)

And the failing boot actually enables it:
[    0.332285] Memory: 495640K/524288K available (8188K kernel code, 647K rwdata, 1504K rodata, 9620K init, 244K bss, 27528K reserved, 0K cma-reserved, 262144K highmem)

so I believe that the partial revert should help.

Anther option is to simply disable CONFIG_HIGHMEM for that platform if it
anyway can't support highmem.
 
> > Another thing I think worth checking is will the system boot with a
> partial
> > revert of 6faea3422e3b ("arch, mm: streamline HIGHMEM freeing") for mips:
> 
> Will try this out next, update the issue and inform you here.
> 
> Thank you
> 
> Markus

-- 
Sincerely yours,
Mike.

AW: HIGHMEM freeing patch breaks Realtek RTL930x builds

[markus.stockhausen]

Hi Mike,

> The successful boot disables highmem:
> [    0.332305] Memory: 495640K/524288K available (8188K kernel code, 647K
rwdata, 1504K rodata, 9620K init, 244K bss, 27528K reserved, 0K
cma-reserved, 0K highmem)
>
> And the failing boot actually enables it:
> [    0.332285] Memory: 495640K/524288K available (8188K kernel code, 647K
rwdata, 1504K rodata, 9620K init, 244K bss, 27528K reserved, 0K
cma-reserved, 262144K highmem)
>
> so I believe that the partial revert should help.

Interesting find. That is strange. On 6.12 (where everything 
works) the 256MB highmem are detected properly.

[    0.242252] Memory: 493784K/524288K available (8373K kernel code, 725K
rwdata, 1820K rodata, 10896K init, 248K bss, 29384K reserved, 0K
cma-reserved, 262144K highmem)

Additionally I identified some spooky highmem 
initialization in vendors SDK prom.c. We never
used that before. I added bootlog+code snippet 
to the github issue [1].

Just to be sure. Do you expect highmem to be still
detected/advertised with 6.15+? If yes I will bisect 
where the highmem detection breaks prior to the 
"suspicous" commit.

Markus

[1] https://github.com/openwrt/openwrt/issues/21323

AW: HIGHMEM freeing patch breaks Realtek RTL930x builds

[markus.stockhausen]

Hi Mike,

> Additionally I identified some spooky highmem 
> initialization in vendors SDK prom.c. We never
> used that before. I added bootlog+code snippet 
> to the github issue [1].

After checking and testing the vendor prom coding
I finally found a solution to the highmem issue. A
special mapping register needs to be setup prior to
memory initialization. Fixed with [1].

Thanks for helping out here.

Markus

[1]
https://github.com/openwrt/openwrt/pull/21327/commits/02117c1e971b8624417843
7400ab8b2f6a81d2e8

HIGHMEM freeing patch breaks Realtek RTL930x builds

[markus.stockhausen]

Hi,

sorry for being late on this topic but downstream OpenWrt just started
kernel
conversion from 6.12 to 6.18 these days. During preparation of the PR
https://github.com/openwrt/openwrt/pull/21181 we noticed that Realtek 
RTL930x soc based devices with more than 256MB (highmem) do not boot 
any longer. 

These are MIPS 34k 32bit multithreaded SoC with layout 
<0x00000000 0x10000000>, /* 256 MiB lowmem */
<0x20000000 0x10000000>; /* 256 MiB highmem */

Bisecting the issue gave " arch, mm: streamline HIGHMEM freeing" 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/
?h=v6.15-rc1&id=6faea3422e3b4e8de44a55aa3e6e843320da66d2
as the first bad commit. This is back from the 6.15 times.

I have no real idea why removing mem_init_free_highmem() and letting
__free_memory_core() work on the whole memory range gives issues.

We are aligning to upstream very slowly and are still in need of 
downstream patches so here some additional info.

- Until now we never cared about FLATMEM/SPARSEMEM configs

- We are still using dedicated prom.c/setup.c for the devices
https://git.openwrt.org/?p=openwrt/openwrt.git;a=tree;f=target/linux/
realtek/files-6.12/arch/mips/rtl838x;hb=HEAD

Any idea or hint is appreciated.

Thanks in advance.

Markus

Re: HIGHMEM freeing patch breaks Realtek RTL930x builds

[Mike Rapoport]

Hi Markus,

On Sat, Dec 20, 2025 at 09:57:40AM +0100, markus.stockhausen@gmx.de wrote:
> Hi,
> 
> sorry for being late on this topic but downstream OpenWrt just started
> kernel
> conversion from 6.12 to 6.18 these days. During preparation of the PR
> https://github.com/openwrt/openwrt/pull/21181 we noticed that Realtek 
> RTL930x soc based devices with more than 256MB (highmem) do not boot 
> any longer. 
> 
> These are MIPS 34k 32bit multithreaded SoC with layout 
> <0x00000000 0x10000000>, /* 256 MiB lowmem */
> <0x20000000 0x10000000>; /* 256 MiB highmem */
> 
> Bisecting the issue gave " arch, mm: streamline HIGHMEM freeing" 
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/
> ?h=v6.15-rc1&id=6faea3422e3b4e8de44a55aa3e6e843320da66d2
> as the first bad commit. This is back from the 6.15 times.
> 
> I have no real idea why removing mem_init_free_highmem() and letting
> __free_memory_core() work on the whole memory range gives issues.
> 
> We are aligning to upstream very slowly and are still in need of 
> downstream patches so here some additional info.
> 
> - Until now we never cared about FLATMEM/SPARSEMEM configs
> 
> - We are still using dedicated prom.c/setup.c for the devices
> https://git.openwrt.org/?p=openwrt/openwrt.git;a=tree;f=target/linux/
> realtek/files-6.12/arch/mips/rtl838x;hb=HEAD
> 
> Any idea or hint is appreciated.

Can you please send logs from a working kernel and a failing kernel with
"memblock=debug" added to the kernel command line?

Another thing I think worth checking is will the system boot with a partial
revert of 6faea3422e3b ("arch, mm: streamline HIGHMEM freeing") for mips:

diff --git a/arch/mips/mm/init.c b/arch/mips/mm/init.c
index cd04200d0573..be5985155509 100644
--- a/arch/mips/mm/init.c
+++ b/arch/mips/mm/init.c
@@ -419,6 +419,23 @@ void __init arch_zone_limits_init(unsigned long *max_zone_pfns)
 static struct kcore_list kcore_kseg0;
 #endif
 
+static inline void __init mem_init_free_highmem(void)
+{
+#ifdef CONFIG_HIGHMEM
+	unsigned long tmp;
+
+	if (cpu_has_dc_aliases)
+		return;
+
+	for (tmp = highstart_pfn; tmp < highend_pfn; tmp++) {
+		struct page *page = pfn_to_page(tmp);
+
+		if (!memblock_is_memory(PFN_PHYS(tmp)))
+			SetPageReserved(page);
+	}
+#endif
+}
+
 void __init arch_mm_preinit(void)
 {
 	/*
@@ -429,6 +446,7 @@ void __init arch_mm_preinit(void)
 
 	maar_init();
 	setup_zero_pages();	/* Setup zeroed pages.  */
+	mem_init_free_highmem();
 
 #ifdef CONFIG_64BIT
 	if ((unsigned long) &_text > (unsigned long) CKSEG0)
 
> Thanks in advance.
> Markus

-- 
Sincerely yours,
Mike.