All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mike Rapoport <rppt@kernel.org>
To: markus.stockhausen@gmx.de
Cc: tglx@linutronix.de, linux-mm@kvack.org,
	linux-mips@vger.kernel.org, jelonek.jonas@gmail.com,
	'Chris Packham' <Chris.Packham@alliedtelesis.co.nz>,
	hauke@hauke-m.de
Subject: Re: HIGHMEM freeing patch breaks Realtek RTL930x builds
Date: Mon, 29 Dec 2025 21:35:19 +0200	[thread overview]
Message-ID: <aVLX9yLmIBPzI0MQ@kernel.org> (raw)
In-Reply-To: <007d01dc78f2$1ca4bf90$55ee3eb0$@gmx.de>

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.


  reply	other threads:[~2025-12-29 19:35 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-12-29 18:36 HIGHMEM freeing patch breaks Realtek RTL930x builds markus.stockhausen
2025-12-29 19:35 ` Mike Rapoport [this message]
2025-12-29 21:16   ` AW: " markus.stockhausen
2025-12-30 15:31   ` markus.stockhausen
  -- strict thread matches above, loose matches on Subject: below --
2025-12-20  8:57 markus.stockhausen
2025-12-28  9:54 ` Mike Rapoport

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=aVLX9yLmIBPzI0MQ@kernel.org \
    --to=rppt@kernel.org \
    --cc=Chris.Packham@alliedtelesis.co.nz \
    --cc=hauke@hauke-m.de \
    --cc=jelonek.jonas@gmail.com \
    --cc=linux-mips@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=markus.stockhausen@gmx.de \
    --cc=tglx@linutronix.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.