Migo-R (SH7722) vs. NUMA
Hi!
I've been working on upgrading the kernel for our Migo-R (SH7722) board From ancient 2.6.30.6 to something more modern, 3.2. But, based on migor_defconfig, it wouldn't boot, and instead just hang after the boot loader. I bisected this to commit 19d8f84f86af867abee174be8bf1e4941a59143d (2010-05-10). (To build this tree, you need to cherry-pick 06225c08ec2ad0f0dec063df7f08773a8358db12 and apply the equivalent of c77b29db74a0ea4fdce0564a63b8876798625d64 to arch/sh/kernel/setup.c.)
By chance I figured out that disabling NUMA support (which is enabled for migor_defconfig) would make it work again for this tree, as well as later versions, such as the 3.2 release. I guess this should be fixed properly?
Grüße,
Thomas
Hi Thomas
Quoted 9 lines
I've been working on upgrading the kernel for our Migo-R (SH7722) board From ancient 2.6.30.6 to something more modern, 3.2. But, based on
migor_defconfig, it wouldn't boot, and instead just hang after the boot loader. I bisected this to commit19d8f84f86af867abee174be8bf1e4941a59143d(2010-05-10). (To build this tree, you need to cherry-pick06225c08ec2ad0f0dec063df7f08773a8358db12and apply the equivalent ofc77b29db74a0ea4fdce0564a63b8876798625d64toarch/sh/kernel/setup.c.)
Quoted 4 lines
By chance I figured out that disabling NUMA support (which is enabled for
migor_defconfig) would make it work again for this tree, as well as later versions, such as the 3.2 release. I guess this should be fixed properly?
I forgot detail of MIGO-R.
But in my quick check,
my MIGO-R .config doesn't have CONFIG_NUMA since around v2.6.32-rc5
Best regards
---
Kuninori Morimoto
Hi!
Quoted 9 lines · Kuninori Morimoto
Quoted 9 lines
I've been working on upgrading the kernel for our Migo-R (SH7722) board From ancient 2.6.30.6 to something more modern, 3.2. But, based on
migor_defconfig, it wouldn't boot, and instead just hang after the boot loader. I bisected this to commit19d8f84f86af867abee174be8bf1e4941a59143d(2010-05-10). (To build this tree, you need to cherry-pick06225c08ec2ad0f0dec063df7f08773a8358db12and apply the equivalent ofc77b29db74a0ea4fdce0564a63b8876798625d64toarch/sh/kernel/setup.c.)
Quoted 8 lines
Quoted 4 lines
By chance I figured out that disabling NUMA support (which is enabled for
migor_defconfig) would make it work again for this tree, as well as later versions, such as the 3.2 release. I guess this should be fixed properly?I forgot detail of MIGO-R.
But in my quick check,
my MIGO-R .config doesn't haveCONFIG_NUMAsince around v2.6.32-rc5
Hmm, where do you see/check that?
$ git blame -L /^CONFIG_NUMA/,+1 v3.2 -- arch/sh/configs/migor_defconfig
70f784ec (Magnus Damm 2008-02-07 00:38:24 +0900 16) CONFIG_NUMA=yGrüße,
Thomas
Hi Thomas
Quoted 8 lines
Quoted 3 lines
I forgot detail of MIGO-R.
But in my quick check,
my MIGO-R .config doesn't haveCONFIG_NUMAsince around v2.6.32-rc5Hmm, where do you see/check that?
$ git blame -L /^CONFIG_NUMA/,+1 v3.2 -- arch/sh/configs/migor_defconfig 70f784ec (Magnus Damm 2008-02-07 00:38:24 +0900 16) CONFIG_NUMA=y
Ahh.. sorry for my confusion.
It was not migor_defconfig.
It is my local .config series which worked correctly on migo-r each linux version :) unfortunately (?) defconfig sometimes doesn't work...
Best regards
---
Kuninori Morimoto
Hi!
Quoted 6 lines · Kuninori Morimoto
Quoted 6 lines
Quoted 3 lines
I forgot detail of MIGO-R.
But in my quick check,
my MIGO-R .config doesn't haveCONFIG_NUMAsince around v2.6.32-rc5Hmm, where do you see/check that?
Quoted 7 lines
Quoted 2 lines
$ git blame -L /^CONFIG_NUMA/,+1 v3.2 -- arch/sh/configs/migor_defconfig 70f784ec (Magnus Damm 2008-02-07 00:38:24 +0900 16) CONFIG_NUMA=yAhh.. sorry for my confusion.
It was notmigor_defconfig.
It is my local .config series which worked correctly on migo-r each linux version :) unfortunately (?) defconfig sometimes doesn't work...
I'm not an expert on this, but here is what I think should be done: a) fix CONFIG_NUMA (apparently it used to work before the commit I referenced in my original email), or b) tag it as broken/unsupported and make sure it can't be enabled (and obviously don't enable it in the default configuration). Which of the two is it?
Grüße,
Thomas
Quoted 17 lines · Thomas Schwinge
Hi!
Quoted 6 lines · Kuninori Morimoto
Quoted 6 lines
Quoted 3 lines
I forgot detail of MIGO-R.
But in my quick check,
my MIGO-R .config doesn't haveCONFIG_NUMAsince around v2.6.32-rc5Hmm, where do you see/check that?
Quoted 7 lines
Quoted 2 lines
$ git blame -L /^CONFIG_NUMA/,+1 v3.2 -- arch/sh/configs/migor_defconfig 70f784ec (Magnus Damm 2008-02-07 00:38:24 +0900 16) CONFIG_NUMA=yAhh.. sorry for my confusion.
It was notmigor_defconfig.
It is my local .config series which worked correctly on migo-r each linux version :) unfortunately (?) defconfig sometimes doesn't work...
Quoted 6 lines
I'm not an expert on this, but here is what I think should be done: a) fix
CONFIG_NUMA(apparently it used to work before the commit I referenced in my original email), or b) tag it as broken/unsupported and make sure it can't be enabled (and obviously don't enable it in the default configuration). Which of the two is it?
If memory serves, this is one of the things that was outstanding from the memblock conversion, which then got put on hold again while the memblock API refactorig was taking place. Now that things have settled we can take a look at fixing up whats outstanding. We can flag it as broken in the interim I suppose, although since most people enable broken unconditionally anyways it doesn't make much of a functional difference.