Re: [PATCH 10/13] arch, mm: set high_memory in free_area_init()
Mike Rapoport <[email protected]>
| Newsgroups | org.kernel.vger.linux-hexagon,dev.linux.lists.loongarch,org.infradead.lists.linux-riscv,org.infradead.lists.linux-snps-arc,org.infradead.lists.linux-um,org.kernel.vger.linux-alpha,org.kernel.vger.linux-arch,org.kernel.vger.linux-csky,org.kernel.vger.linux-kernel,org.kernel.vger.linux-m68k,org.kernel.vger.linux-mips,org.kernel.vger.linux-openrisc,org.kernel.vger.linux-parisc,org.kernel.vger.linux-s390,org.kernel.vger.linux-sh,org.kernel.vger.sparclinux,org.kvack.linux-mm,org.ozlabs.lists.linuxppc-dev |
|---|---|
| Message-ID | <[email protected]> |
Hi Mark, On Tue, Mar 11, 2025 at 05:51:06PM +0000, Mark Brown wrote: > On Thu, Mar 06, 2025 at 08:51:20PM +0200, Mike Rapoport wrote: > > From: "Mike Rapoport (Microsoft)" <[email protected]> > > > > high_memory defines upper bound on the directly mapped memory. > > This bound is defined by the beginning of ZONE_HIGHMEM when a system has > > high memory and by the end of memory otherwise. > > > > All this is known to generic memory management initialization code that > > can set high_memory while initializing core mm structures. > > > > Remove per-architecture calculation of high_memory and add a generic > > version to free_area_init(). > > This patch appears to be causing breakage on a number of 32 bit arm > platforms, including qemu's virt-2.11,gic-version=3. Affected platforms > die on boot with no output, a bisect with qemu points at this commit and > those for physical platforms appear to be converging on the same place. Can you share how this can be reproduced with qemu? -- Sincerely yours, Mike.