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 :)