linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
* Re: HIGHMEM freeing patch breaks Realtek RTL930x builds
@ 2025-12-29 18:36 markus.stockhausen
  2025-12-29 19:35 ` Mike Rapoport
  0 siblings, 1 reply; 4+ messages in thread
From: markus.stockhausen @ 2025-12-29 18:36 UTC (permalink / raw)
  To: 'Mike Rapoport'
  Cc: tglx, linux-mm, linux-mips, jelonek.jonas,
	'Chris Packham',
	hauke

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



^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: HIGHMEM freeing patch breaks Realtek RTL930x builds
  2025-12-29 18:36 HIGHMEM freeing patch breaks Realtek RTL930x builds markus.stockhausen
@ 2025-12-29 19:35 ` Mike Rapoport
  2025-12-29 21:16   ` AW: " markus.stockhausen
  2025-12-30 15:31   ` markus.stockhausen
  0 siblings, 2 replies; 4+ messages in thread
From: Mike Rapoport @ 2025-12-29 19:35 UTC (permalink / raw)
  To: markus.stockhausen
  Cc: tglx, linux-mm, linux-mips, jelonek.jonas,
	'Chris Packham',
	hauke

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.


^ permalink raw reply	[flat|nested] 4+ messages in thread

* AW: HIGHMEM freeing patch breaks Realtek RTL930x builds
  2025-12-29 19:35 ` Mike Rapoport
@ 2025-12-29 21:16   ` markus.stockhausen
  2025-12-30 15:31   ` markus.stockhausen
  1 sibling, 0 replies; 4+ messages in thread
From: markus.stockhausen @ 2025-12-29 21:16 UTC (permalink / raw)
  To: 'Mike Rapoport'
  Cc: tglx, linux-mm, linux-mips, jelonek.jonas,
	'Chris Packham',
	hauke

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




^ permalink raw reply	[flat|nested] 4+ messages in thread

* AW: HIGHMEM freeing patch breaks Realtek RTL930x builds
  2025-12-29 19:35 ` Mike Rapoport
  2025-12-29 21:16   ` AW: " markus.stockhausen
@ 2025-12-30 15:31   ` markus.stockhausen
  1 sibling, 0 replies; 4+ messages in thread
From: markus.stockhausen @ 2025-12-30 15:31 UTC (permalink / raw)
  To: 'Mike Rapoport'
  Cc: tglx, linux-mm, linux-mips, jelonek.jonas,
	'Chris Packham',
	hauke

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




^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2025-12-30 15:31 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2025-12-29 18:36 HIGHMEM freeing patch breaks Realtek RTL930x builds markus.stockhausen
2025-12-29 19:35 ` Mike Rapoport
2025-12-29 21:16   ` AW: " markus.stockhausen
2025-12-30 15:31   ` markus.stockhausen

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox