From: Tobias Wolf <[email protected]>
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.
This patch adds the originally intended prerequisite again.
This patch has been present in OpenWrt tree for over 2 years:
https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=93bfafb8dc209f153022796d9e747149e66cc29e
Fixes: 67a3ba25aa95 ("MIPS: Fix incorrect mem=X@Y handling")
Signed-off-by: Tobias Wolf <[email protected]>
[Reword commit message]
Signed-off-by: Ilya Lipnitskiy <[email protected]>
Cc: Marcin Nowakowski <[email protected]>
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
---
arch/mips/kernel/setup.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
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;
--
2.30.1
On Sun, Mar 07, 2021 at 11:40:30AM -0800, Ilya Lipnitskiy wrote:
> From: Tobias Wolf <[email protected]>
>
> 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.
--
Crap can work. Given enough thrust pigs will fly, but it's not necessarily a
good idea. [ RFC1925, 2.3 ]
Hi Thomas,
On Fri, Mar 12, 2021 at 7:19 AM Thomas Bogendoerfer
<[email protected]> wrote:
>
> On Sun, Mar 07, 2021 at 11:40:30AM -0800, Ilya Lipnitskiy wrote:
> > From: Tobias Wolf <[email protected]>
> >
> > 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
> <[email protected]> wrote:
> >
> > On Sun, Mar 07, 2021 at 11:40:30AM -0800, Ilya Lipnitskiy wrote:
> > > From: Tobias Wolf <[email protected]>
> > >
> > > 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?
--
Sincerely yours,
Mike.
Hi Mike,
On Tue, Mar 16, 2021 at 11:33 PM Mike Rapoport <[email protected]> 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
> > <[email protected]> wrote:
> > >
> > > On Sun, Mar 07, 2021 at 11:40:30AM -0800, Ilya Lipnitskiy wrote:
> > > > From: Tobias Wolf <[email protected]>
> > > >
> > > > 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
RT288X systems may have a non-zero ramstart causing problems with memory
reservations and boot hangs, as well as messages like:
Wasting 1048576 bytes for tracking 32768 unused pages
Both are alleviated by selecting MIPS_AUTO_PFN_OFFSET for such
platforms.
Tested on a Belkin F5D8235 v1 RT2880 device.
Link: https://lore.kernel.org/linux-mips/20180820233111.xww5232dxbuouf4n@pburton-laptop/
Signed-off-by: Ilya Lipnitskiy <[email protected]>
Cc: Mike Rapoport <[email protected]>
---
arch/mips/ralink/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/mips/ralink/Kconfig b/arch/mips/ralink/Kconfig
index c20c44788b62..7c6de7f8484e 100644
--- a/arch/mips/ralink/Kconfig
+++ b/arch/mips/ralink/Kconfig
@@ -31,6 +31,7 @@ choice
config SOC_RT288X
bool "RT288x"
+ select MIPS_AUTO_PFN_OFFSET
select MIPS_L1_CACHE_SHIFT_4
select HAVE_LEGACY_CLK
select HAVE_PCI
--
2.31.1
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 <[email protected]> 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
> > > <[email protected]> wrote:
> > > >
> > > > On Sun, Mar 07, 2021 at 11:40:30AM -0800, Ilya Lipnitskiy wrote:
> > > > > From: Tobias Wolf <[email protected]>
> > > > >
> > > > > 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.
--
Crap can work. Given enough thrust pigs will fly, but it's not necessarily a
good idea. [ RFC1925, 2.3 ]
On Sat, Apr 03, 2021 at 07:11:26PM -0700, Ilya Lipnitskiy wrote:
> RT288X systems may have a non-zero ramstart causing problems with memory
> reservations and boot hangs, as well as messages like:
> Wasting 1048576 bytes for tracking 32768 unused pages
>
> Both are alleviated by selecting MIPS_AUTO_PFN_OFFSET for such
> platforms.
>
> Tested on a Belkin F5D8235 v1 RT2880 device.
>
> Link: https://lore.kernel.org/linux-mips/20180820233111.xww5232dxbuouf4n@pburton-laptop/
>
> Signed-off-by: Ilya Lipnitskiy <[email protected]>
> Cc: Mike Rapoport <[email protected]>
> ---
> arch/mips/ralink/Kconfig | 1 +
> 1 file changed, 1 insertion(+)
applied to mips-next.
Thomas.
--
Crap can work. Given enough thrust pigs will fly, but it's not necessarily a
good idea. [ RFC1925, 2.3 ]
On Mon, Apr 12, 2021 at 11:45 PM Ilya Lipnitskiy
<[email protected]> wrote:
>
> Hi Thomas,
>
> On Tue, Apr 6, 2021 at 6:18 AM Thomas Bogendoerfer
> <[email protected]> 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 <[email protected]> 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
> > > > > <[email protected]> wrote:
> > > > > >
> > > > > > On Sun, Mar 07, 2021 at 11:40:30AM -0800, Ilya Lipnitskiy wrote:
> > > > > > > From: Tobias Wolf <[email protected]>
> > > > > > >
> > > > > > > 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
Hi Thomas,
On Tue, Apr 6, 2021 at 6:18 AM Thomas Bogendoerfer
<[email protected]> 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 <[email protected]> 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
> > > > <[email protected]> wrote:
> > > > >
> > > > > On Sun, Mar 07, 2021 at 11:40:30AM -0800, Ilya Lipnitskiy wrote:
> > > > > > From: Tobias Wolf <[email protected]>
> > > > > >
> > > > > > 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:45PM -0700, Ilya Lipnitskiy wrote:
> Hi Thomas,
>
> On Tue, Apr 6, 2021 at 6:18 AM Thomas Bogendoerfer
> <[email protected]> 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 <[email protected]> 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
> > > > > <[email protected]> wrote:
> > > > > >
> > > > > > On Sun, Mar 07, 2021 at 11:40:30AM -0800, Ilya Lipnitskiy wrote:
> > > > > > > From: Tobias Wolf <[email protected]>
> > > > > > >
> > > > > > > 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 :)
--
Sincerely yours,
Mike.