Migo-R (SH7722) vs. NUMA

Migo-R (SH7722) vs. NUMA

[Thomas Schwinge]

[-- Attachment #1: Type: text/plain, Size: 753 bytes --]

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

[-- Attachment #2: Type: application/pgp-signature, Size: 489 bytes --]

Re: Migo-R (SH7722) vs. NUMA

[Kuninori Morimoto]

Hi Thomas

> 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?

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

Re: Migo-R (SH7722) vs. NUMA

[Thomas Schwinge]

[-- Attachment #1: Type: text/plain, Size: 1221 bytes --]

Hi!

On Wed, 7 Mar 2012 17:24:30 -0800, Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> wrote:
> > 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?
> 
> 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

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=y


Grüße,
 Thomas

[-- Attachment #2: Type: application/pgp-signature, Size: 489 bytes --]

Re: Migo-R (SH7722) vs. NUMA

[Kuninori Morimoto]

Hi Thomas

> > 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
> 
> 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=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

Re: Migo-R (SH7722) vs. NUMA

[Thomas Schwinge]

[-- Attachment #1: Type: text/plain, Size: 1019 bytes --]

Hi!

On Thu, 8 Mar 2012 00:04:28 -0800, Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> wrote:
> > > 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
> > 
> > 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=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...

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

[-- Attachment #2: Type: application/pgp-signature, Size: 489 bytes --]

Re: Migo-R (SH7722) vs. NUMA

[Paul Mundt]

On Thu, Mar 08, 2012 at 03:22:08PM +0100, Thomas Schwinge wrote:
> Hi!
> 
> On Thu, 8 Mar 2012 00:04:28 -0800, Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> wrote:
> > > > 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
> > > 
> > > 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=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...
> 
> 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.