| Message ID | 20210307194030.8007-1-ilya.lipnitskiy@gmail.com (mailing list archive) |
|---|---|
| State | Superseded |
| Headers | show |
| Series | MIPS: fix memory reservation for non-usermem setups | expand |
On Sun, Mar 07, 2021 at 11:40:30AM -0800, Ilya Lipnitskiy wrote: > From: Tobias Wolf <dev-NTEO@vplace.de> > > Commit 67a3ba25aa95 ("MIPS: Fix incorrect mem=X@Y handling") introduced a new > issue for rt288x where "PHYS_OFFSET" is 0x0 but the calculated "ramstart" is > not. As the prerequisite of custom memory map has been removed, this results > in the full memory range of 0x0 - 0x8000000 to be marked as reserved for this > platform. and where is the problem here ? Thomas.
Hi Thomas, On Fri, Mar 12, 2021 at 7:19 AM Thomas Bogendoerfer <tsbogend@alpha.franken.de> wrote: > > On Sun, Mar 07, 2021 at 11:40:30AM -0800, Ilya Lipnitskiy wrote: > > From: Tobias Wolf <dev-NTEO@vplace.de> > > > > Commit 67a3ba25aa95 ("MIPS: Fix incorrect mem=X@Y handling") introduced a new > > issue for rt288x where "PHYS_OFFSET" is 0x0 but the calculated "ramstart" is > > not. As the prerequisite of custom memory map has been removed, this results > > in the full memory range of 0x0 - 0x8000000 to be marked as reserved for this > > platform. > > and where is the problem here ? Turns out this was already attempted to be upstreamed - not clear why it wasn't merged. Context: https://lore.kernel.org/linux-mips/6504517.U6H5IhoIOn@loki/ I hope the thread above helps you understand the problem. > > Thomas. > > -- > Crap can work. Given enough thrust pigs will fly, but it's not necessarily a > good idea. [ RFC1925, 2.3 ] Ilya
Hi Ilya, On Tue, Mar 16, 2021 at 10:10:09PM -0700, Ilya Lipnitskiy wrote: > Hi Thomas, > > On Fri, Mar 12, 2021 at 7:19 AM Thomas Bogendoerfer > <tsbogend@alpha.franken.de> wrote: > > > > On Sun, Mar 07, 2021 at 11:40:30AM -0800, Ilya Lipnitskiy wrote: > > > From: Tobias Wolf <dev-NTEO@vplace.de> > > > > > > Commit 67a3ba25aa95 ("MIPS: Fix incorrect mem=X@Y handling") introduced a new > > > issue for rt288x where "PHYS_OFFSET" is 0x0 but the calculated "ramstart" is > > > not. As the prerequisite of custom memory map has been removed, this results > > > in the full memory range of 0x0 - 0x8000000 to be marked as reserved for this > > > platform. > > > > and where is the problem here ? > Turns out this was already attempted to be upstreamed - not clear why > it wasn't merged. Context: > https://lore.kernel.org/linux-mips/6504517.U6H5IhoIOn@loki/ > > I hope the thread above helps you understand the problem. The memory initialization was a bit different then. Do you still see the same problem?
Hi Mike, On Tue, Mar 16, 2021 at 11:33 PM Mike Rapoport <rppt@kernel.org> wrote: > > Hi Ilya, > > On Tue, Mar 16, 2021 at 10:10:09PM -0700, Ilya Lipnitskiy wrote: > > Hi Thomas, > > > > On Fri, Mar 12, 2021 at 7:19 AM Thomas Bogendoerfer > > <tsbogend@alpha.franken.de> wrote: > > > > > > On Sun, Mar 07, 2021 at 11:40:30AM -0800, Ilya Lipnitskiy wrote: > > > > From: Tobias Wolf <dev-NTEO@vplace.de> > > > > > > > > Commit 67a3ba25aa95 ("MIPS: Fix incorrect mem=X@Y handling") introduced a new > > > > issue for rt288x where "PHYS_OFFSET" is 0x0 but the calculated "ramstart" is > > > > not. As the prerequisite of custom memory map has been removed, this results > > > > in the full memory range of 0x0 - 0x8000000 to be marked as reserved for this > > > > platform. > > > > > > and where is the problem here ? > > Turns out this was already attempted to be upstreamed - not clear why > > it wasn't merged. Context: > > https://lore.kernel.org/linux-mips/6504517.U6H5IhoIOn@loki/ > > > > I hope the thread above helps you understand the problem. > > The memory initialization was a bit different then. Do you still see the > same problem? Thanks for asking. I obtained a RT2880 device and gave it a try. It hangs at boot without this patch, however selecting MIPS_AUTO_PFN_OFFSET fixes it. Also, no more messages like "Wasting 1048576 bytes for tracking 32768 unused pages". MIPS_AUTO_PFN_OFFSET was suggested by Paul Burton here: https://lore.kernel.org/linux-mips/20180820233111.xww5232dxbuouf4n@pburton-laptop/ I will supersede this patch with one that simply selects MIPS_AUTO_PFN_OFFSET for this SOC. Ilya
On Sat, Apr 03, 2021 at 07:02:13PM -0700, Ilya Lipnitskiy wrote: > Hi Mike, > > On Tue, Mar 16, 2021 at 11:33 PM Mike Rapoport <rppt@kernel.org> wrote: > > > > Hi Ilya, > > > > On Tue, Mar 16, 2021 at 10:10:09PM -0700, Ilya Lipnitskiy wrote: > > > Hi Thomas, > > > > > > On Fri, Mar 12, 2021 at 7:19 AM Thomas Bogendoerfer > > > <tsbogend@alpha.franken.de> wrote: > > > > > > > > On Sun, Mar 07, 2021 at 11:40:30AM -0800, Ilya Lipnitskiy wrote: > > > > > From: Tobias Wolf <dev-NTEO@vplace.de> > > > > > > > > > > Commit 67a3ba25aa95 ("MIPS: Fix incorrect mem=X@Y handling") introduced a new > > > > > issue for rt288x where "PHYS_OFFSET" is 0x0 but the calculated "ramstart" is > > > > > not. As the prerequisite of custom memory map has been removed, this results > > > > > in the full memory range of 0x0 - 0x8000000 to be marked as reserved for this > > > > > platform. > > > > > > > > and where is the problem here ? > > > Turns out this was already attempted to be upstreamed - not clear why > > > it wasn't merged. Context: > > > https://lore.kernel.org/linux-mips/6504517.U6H5IhoIOn@loki/ > > > > > > I hope the thread above helps you understand the problem. > > > > The memory initialization was a bit different then. Do you still see the > > same problem? > Thanks for asking. I obtained a RT2880 device and gave it a try. It > hangs at boot without this patch, however selecting can you provide debug logs with memblock=debug for both good and bad kernels ? I'm curious what's the reason for failing allocation... Thomas.
Hi Thomas, On Tue, Apr 6, 2021 at 6:18 AM Thomas Bogendoerfer <tsbogend@alpha.franken.de> wrote: > > On Sat, Apr 03, 2021 at 07:02:13PM -0700, Ilya Lipnitskiy wrote: > > Hi Mike, > > > > On Tue, Mar 16, 2021 at 11:33 PM Mike Rapoport <rppt@kernel.org> wrote: > > > > > > Hi Ilya, > > > > > > On Tue, Mar 16, 2021 at 10:10:09PM -0700, Ilya Lipnitskiy wrote: > > > > Hi Thomas, > > > > > > > > On Fri, Mar 12, 2021 at 7:19 AM Thomas Bogendoerfer > > > > <tsbogend@alpha.franken.de> wrote: > > > > > > > > > > On Sun, Mar 07, 2021 at 11:40:30AM -0800, Ilya Lipnitskiy wrote: > > > > > > From: Tobias Wolf <dev-NTEO@vplace.de> > > > > > > > > > > > > Commit 67a3ba25aa95 ("MIPS: Fix incorrect mem=X@Y handling") introduced a new > > > > > > issue for rt288x where "PHYS_OFFSET" is 0x0 but the calculated "ramstart" is > > > > > > not. As the prerequisite of custom memory map has been removed, this results > > > > > > in the full memory range of 0x0 - 0x8000000 to be marked as reserved for this > > > > > > platform. > > > > > > > > > > and where is the problem here ? > > > > Turns out this was already attempted to be upstreamed - not clear why > > > > it wasn't merged. Context: > > > > https://lore.kernel.org/linux-mips/6504517.U6H5IhoIOn@loki/ > > > > > > > > I hope the thread above helps you understand the problem. > > > > > > The memory initialization was a bit different then. Do you still see the > > > same problem? > > Thanks for asking. I obtained a RT2880 device and gave it a try. It > > hangs at boot without this patch, however selecting > > can you provide debug logs with memblock=debug for both good and bad > kernels ? I'm curious what's the reason for failing allocation... Sorry for taking a while to respond. See attached. FWIW, it seems these are the lines that stand out in hang.log: [ 0.000000] memblock_reserve: [0x00000000-0x07ffffff] setup_arch+0x214/0x5d8 [ 0.000000] Wasting 1048576 bytes for tracking 32768 unused pages ... [ 0.000000] reserved[0x0] [0x00000000-0x087137aa], 0x087137ab bytes flags: 0x0 Ilya
On Mon, Apr 12, 2021 at 11:45 PM Ilya Lipnitskiy <ilya.lipnitskiy@gmail.com> wrote: > > Hi Thomas, > > On Tue, Apr 6, 2021 at 6:18 AM Thomas Bogendoerfer > <tsbogend@alpha.franken.de> wrote: > > > > On Sat, Apr 03, 2021 at 07:02:13PM -0700, Ilya Lipnitskiy wrote: > > > Hi Mike, > > > > > > On Tue, Mar 16, 2021 at 11:33 PM Mike Rapoport <rppt@kernel.org> wrote: > > > > > > > > Hi Ilya, > > > > > > > > On Tue, Mar 16, 2021 at 10:10:09PM -0700, Ilya Lipnitskiy wrote: > > > > > Hi Thomas, > > > > > > > > > > On Fri, Mar 12, 2021 at 7:19 AM Thomas Bogendoerfer > > > > > <tsbogend@alpha.franken.de> wrote: > > > > > > > > > > > > On Sun, Mar 07, 2021 at 11:40:30AM -0800, Ilya Lipnitskiy wrote: > > > > > > > From: Tobias Wolf <dev-NTEO@vplace.de> > > > > > > > > > > > > > > Commit 67a3ba25aa95 ("MIPS: Fix incorrect mem=X@Y handling") introduced a new > > > > > > > issue for rt288x where "PHYS_OFFSET" is 0x0 but the calculated "ramstart" is > > > > > > > not. As the prerequisite of custom memory map has been removed, this results > > > > > > > in the full memory range of 0x0 - 0x8000000 to be marked as reserved for this > > > > > > > platform. > > > > > > > > > > > > and where is the problem here ? > > > > > Turns out this was already attempted to be upstreamed - not clear why > > > > > it wasn't merged. Context: > > > > > https://lore.kernel.org/linux-mips/6504517.U6H5IhoIOn@loki/ > > > > > > > > > > I hope the thread above helps you understand the problem. > > > > > > > > The memory initialization was a bit different then. Do you still see the > > > > same problem? > > > Thanks for asking. I obtained a RT2880 device and gave it a try. It > > > hangs at boot without this patch, however selecting > > > > can you provide debug logs with memblock=debug for both good and bad > > kernels ? I'm curious what's the reason for failing allocation... > Sorry for taking a while to respond. See attached. > FWIW, it seems these are the lines that stand out in hang.log: > [ 0.000000] memblock_reserve: [0x00000000-0x07ffffff] setup_arch+0x214/0x5d8 > [ 0.000000] Wasting 1048576 bytes for tracking 32768 unused pages > ... > [ 0.000000] reserved[0x0] [0x00000000-0x087137aa], 0x087137ab > bytes flags: 0x0 Just to be clear, good.log is mips-next tip (dbd815c0dcca) and hang.log is the same with MIPS_AUTO_PFN_OFFSET _NOT_ selected. Ilya
On Mon, Apr 12, 2021 at 11:45:45PM -0700, Ilya Lipnitskiy wrote: > Hi Thomas, > > On Tue, Apr 6, 2021 at 6:18 AM Thomas Bogendoerfer > <tsbogend@alpha.franken.de> wrote: > > > > On Sat, Apr 03, 2021 at 07:02:13PM -0700, Ilya Lipnitskiy wrote: > > > Hi Mike, > > > > > > On Tue, Mar 16, 2021 at 11:33 PM Mike Rapoport <rppt@kernel.org> wrote: > > > > > > > > Hi Ilya, > > > > > > > > On Tue, Mar 16, 2021 at 10:10:09PM -0700, Ilya Lipnitskiy wrote: > > > > > Hi Thomas, > > > > > > > > > > On Fri, Mar 12, 2021 at 7:19 AM Thomas Bogendoerfer > > > > > <tsbogend@alpha.franken.de> wrote: > > > > > > > > > > > > On Sun, Mar 07, 2021 at 11:40:30AM -0800, Ilya Lipnitskiy wrote: > > > > > > > From: Tobias Wolf <dev-NTEO@vplace.de> > > > > > > > > > > > > > > Commit 67a3ba25aa95 ("MIPS: Fix incorrect mem=X@Y handling") introduced a new > > > > > > > issue for rt288x where "PHYS_OFFSET" is 0x0 but the calculated "ramstart" is > > > > > > > not. As the prerequisite of custom memory map has been removed, this results > > > > > > > in the full memory range of 0x0 - 0x8000000 to be marked as reserved for this > > > > > > > platform. > > > > > > > > > > > > and where is the problem here ? > > > > > Turns out this was already attempted to be upstreamed - not clear why > > > > > it wasn't merged. Context: > > > > > https://lore.kernel.org/linux-mips/6504517.U6H5IhoIOn@loki/ > > > > > > > > > > I hope the thread above helps you understand the problem. > > > > > > > > The memory initialization was a bit different then. Do you still see the > > > > same problem? > > > Thanks for asking. I obtained a RT2880 device and gave it a try. It > > > hangs at boot without this patch, however selecting > > > > can you provide debug logs with memblock=debug for both good and bad > > kernels ? I'm curious what's the reason for failing allocation... > > Sorry for taking a while to respond. See attached. > FWIW, it seems these are the lines that stand out in hang.log: > [ 0.000000] memblock_reserve: [0x00000000-0x07ffffff] setup_arch+0x214/0x5d8 > [ 0.000000] Wasting 1048576 bytes for tracking 32768 unused pages > ... > [ 0.000000] reserved[0x0] [0x00000000-0x087137aa], 0x087137ab > bytes flags: 0x0 > > Ilya > ---------------------------CONTINUTES-BOOTING-NORMALLY----------------------- > [ 0.000000] MEMBLOCK configuration: > [ 0.000000] memory size = 0x02000000 reserved size = 0x0875a542 > [ 0.000000] memory.cnt = 0x1 > [ 0.000000] memory[0x0] [0x08000000-0x09ffffff], 0x02000000 bytes flags: 0x0 > [ 0.000000] reserved.cnt = 0x5 > [ 0.000000] reserved[0x0] [0x00000000-0x087137aa], 0x087137ab bytes flags: 0x0 > [ 0.000000] reserved[0x1] [0x087137b0-0x087137b3], 0x00000004 bytes flags: 0x0 > [ 0.000000] reserved[0x2] [0x087137c0-0x08715276], 0x00001ab7 bytes flags: 0x0 > [ 0.000000] reserved[0x3] [0x08715278-0x0871a533], 0x000052bc bytes flags: 0x0 > [ 0.000000] reserved[0x4] [0x0871a540-0x0875a55f], 0x00040020 bytes flags: 0x0 ... > [ 0.000000] Memory: 25168K/32768K available (4299K kernel code, 575K rwdata, 952K rodata, 1204K init, 205K bss, 7600K reserved, 0K cma-reserved) > ----------------------------------------HANGS-FOREVER-HERE--------------------------------- I'd say that with ARCH_PFN_OFFSET set to 0 and actual memory start address at 0x08000000 any attempt to do pfn_to_page()/page_to_pfn()/page_address() will give an incorrect result and will crash the system. No idea why the crash is silent, though :)
diff --git a/arch/mips/kernel/setup.c b/arch/mips/kernel/setup.c index 279be0153f8b..97e3a0db651b 100644 --- a/arch/mips/kernel/setup.c +++ b/arch/mips/kernel/setup.c @@ -251,6 +251,8 @@ static unsigned long __init init_initrd(void) * Initialize the bootmem allocator. It also setup initrd related data * if needed. */ +static int usermem __initdata; + #if defined(CONFIG_SGI_IP27) || (defined(CONFIG_CPU_LOONGSON64) && defined(CONFIG_NUMA)) static void __init bootmem_init(void) @@ -290,7 +292,7 @@ static void __init bootmem_init(void) /* * Reserve any memory between the start of RAM and PHYS_OFFSET */ - if (ramstart > PHYS_OFFSET) + if (usermem && ramstart > PHYS_OFFSET) memblock_reserve(PHYS_OFFSET, ramstart - PHYS_OFFSET); if (PFN_UP(ramstart) > ARCH_PFN_OFFSET) { @@ -338,8 +340,6 @@ static void __init bootmem_init(void) #endif /* CONFIG_SGI_IP27 */ -static int usermem __initdata; - static int __init early_parse_mem(char *p) { phys_addr_t start, size;