2.6.22-git hangs during boot on PowerBook G3 in 0.0 seconds

Hi,

I'm trying to boot a new git kernel (2.6.22-g589f1e81), but it hangs
very early (the timestamp is still on 0.000000).

All messages on screen (typed in, don't have a digital camera...):

[    0.000000] Using PowerMac machine description
[    0.000000] Total memory = 320MB; using 1024kB for hash table (at cff00000)
[    0.000000] Linux version 2.6.22-g589f1e81 (rutger@wingding) (gcc version 4.0.2) #9 Sat Jul 21 18:48:07 CEST 2007
[    0.000000] Found a Paddington mac-io controller, rev: 0, mapped at 0xfdf80000
[    0.000000] PowerMac motherboard: PowerBook 101 (Lombard)
[    0.000000] PMU driver v2 initialized for 1999 Powerbook G3, firmware: 0b
[    0.000000] console [udbg0] enabled
setup_arch: bootmem
[    0.000000] Found Grackle (MPC106) PCI host bridge at 0x0000000080000000. Firmware bus number: 0->0
*hang*

Remarks:
   - 2.6.22-rc4 also hangs
   - compiled with gcc 4.1.2 (prerelease in Debian unstable) also hangs
   - 2.6.21-g9f90b997 does not hang

.config attached.

Known problem?
Any one any ideas?

-- 
Rutger Nijlunsing ---------------------------------- eludias ed dse.nl
never attribute to a conspiracy which can be explained by incompetence
----------------------------------------------------------------------

On Sat, Jul 21, 2007 at 09:21:43PM +0200, Rutger Nijlunsing wrote:

Hi,

I'm trying to boot a new git kernel (2.6.22-g589f1e81), but it hangs
very early (the timestamp is still on 0.000000).

After hours bisecting, I found the one-liner which results in the
hang. Now it takes someone else to find out _why_ it causes a hang :)

From 6c13e1b55c1f87ed19f3c4623de3df881779edd7 Mon Sep 17 00:00:00 2001

From: Rutger Nijlunsing <redacted>
Date: Sat, 21 Jul 2007 23:01:22 +0200
Subject: [PATCH] Revert "[POWERPC] Don't complain if size-cells == 0 in prom_parse()"
Status: RO
Content-Length: 866
Lines: 24

After hours of fun git bisecting, finally found the commit to revert
to make my PowerBook G3 Lombard boot again. This does not result in
the complains the reverted commit was revering to.

This reverts commit fd6e9d3945ee122eb513ada8b17296d243c1ce5e.
---
 arch/powerpc/kernel/prom_parse.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/arch/powerpc/kernel/prom_parse.c b/arch/powerpc/kernel/prom_parse.c
index 3786dcc..b5c96af 100644
--- a/arch/powerpc/kernel/prom_parse.c
+++ b/arch/powerpc/kernel/prom_parse.c

@@ -24,7 +24,7 @@
 /* Max address size we deal with */
 #define OF_MAX_ADDR_CELLS	4
 #define OF_CHECK_COUNTS(na, ns)	((na) > 0 && (na) <= OF_MAX_ADDR_CELLS && \
-			(ns) >= 0)
+			(ns) > 0)
 
 static struct of_bus *of_match_bus(struct device_node *np);
 static int __of_address_to_resource(struct device_node *dev,

-- 
1.5.2.2



-- 
Rutger Nijlunsing ---------------------------------- eludias ed dse.nl
never attribute to a conspiracy which can be explained by incompetence
----------------------------------------------------------------------

On Sat, 21 Jul 2007 23:28:45 +0200
Rutger Nijlunsing [off-list ref] wrote:

On Sat, Jul 21, 2007 at 09:21:43PM +0200, Rutger Nijlunsing wrote:

quoted

Hi,

I'm trying to boot a new git kernel (2.6.22-g589f1e81), but it hangs
very early (the timestamp is still on 0.000000).

After hours bisecting, I found the one-liner which results in the
hang. Now it takes someone else to find out _why_ it causes a hang :)

hmm..I hadn't seen this of_translate_address comment:

 * Note: We consider that crossing any level with #size-cells == 0 to mean
 * that translation is impossible (that is we are not dealing with a value
 * that can be mapped to a cpu physical address). This is not really specified
 * that way, but this is traditionally the way IBM at least do things

so I guess even though size-cells can == 0, of_translate_address should
remain oblivious.

From 6c13e1b55c1f87ed19f3c4623de3df881779edd7 Mon Sep 17 00:00:00 2001
From: Rutger Nijlunsing <redacted>
Date: Sat, 21 Jul 2007 23:01:22 +0200
Subject: [PATCH] Revert "[POWERPC] Don't complain if size-cells == 0 in prom_parse()"
Status: RO
Content-Length: 866
Lines: 24

After hours of fun git bisecting, finally found the commit to revert
to make my PowerBook G3 Lombard boot again. This does not result in
the complains the reverted commit was revering to.

..but it does on my MPC8360.

yes, we can revert it, and perhaps do something like:

diff --git a/arch/powerpc/kernel/prom_parse.c b/arch/powerpc/kernel/prom_parse.c
index 3786dcc..92b7177 100644
--- a/arch/powerpc/kernel/prom_parse.c
+++ b/arch/powerpc/kernel/prom_parse.c

@@ -503,7 +503,7 @@ u64 of_translate_address(struct device_node *dev, const u32 
        /* Cound address cells & copy address locally */
        bus->count_cells(dev, &na, &ns);
        if (!OF_CHECK_COUNTS(na, ns)) {
-               printk(KERN_ERR "prom_parse: Bad cell count for %s\n",
+               DBG("prom_parse: Bad cell count for %s\n",
                       dev->full_name);
                goto bail;
        }

@@ -531,7 +531,7 @@ u64 of_translate_address(struct device_node *dev, const u32 
                pbus = of_match_bus(parent);
                pbus->count_cells(dev, &pna, &pns);
                if (!OF_CHECK_COUNTS(pna, pns)) {
-                       printk(KERN_ERR "prom_parse: Bad cell count for %s\n",
+                       DBG("prom_parse: Bad cell count for %s\n",
                               dev->full_name);
                        break;
                }

Ben?

Kim

quoted

After hours of fun git bisecting, finally found the commit to revert
to make my PowerBook G3 Lombard boot again. This does not result in
the complains the reverted commit was revering to.

..but it does on my MPC8360.

In which circumstances are you trying to translate an address with no
size cell ?

I also wonder why it hangs on the powerbook... Rutger, I would expect to
see that complaint warning with the reverted patch, what does it say ?

My Wallstreet (also based on Grackle) doesn't have the problem. Also can
you send me a tarball of /proc/device-tree ?

Cheers,
Ben.

On Tue, 24 Jul 2007 09:55:23 +1000
Benjamin Herrenschmidt [off-list ref] wrote:

quoted

quoted

After hours of fun git bisecting, finally found the commit to revert
to make my PowerBook G3 Lombard boot again. This does not result in
the complains the reverted commit was revering to.

..but it does on my MPC8360.

In which circumstances are you trying to translate an address with no
size cell ?

for the enumerated PHYs. As the original commit comment states, I was
getting these messages:

prom_parse: Bad cell count for /qe@e0100000/mdio@2120/ethernet-phy@00
prom_parse: Bad cell count for /qe@e0100000/mdio@2120/ethernet-phy@01

I also wonder why it hangs on the powerbook... Rutger, I would expect to
see that complaint warning with the reverted patch, what does it say ?

My Wallstreet (also based on Grackle) doesn't have the problem. Also can
you send me a tarball of /proc/device-tree ?

I don't have any of those machines, but it seems that older kernels
running on the Lombard emitted:

device-tree: Duplicate name in /cpus/PowerPC,750@0, renamed to "l2-cache#1"

messages*.  Experimenting with adding two chosen nodes (due to a prior
thread on this list**) results in a hung kernel on the 8360 also, so
perhaps they're related (and the kernel's tolerance to duplicate
entries has changed, which explains where I had seen the chosen node
being renamed).

but yeah, size-cells should be allowed to be 0 (even address-cells) and
it may be the case that the Lombard needs some fixup code.

Kim

* http://lists.infradead.org/pipermail/linux-pcmcia/2007-April/004503.html
** http://ozlabs.org/pipermail/linuxppc-dev/2007-July/039758.html

for the enumerated PHYs. As the original commit comment states, I was
getting these messages:

prom_parse: Bad cell count for /qe@e0100000/mdio@2120/ethernet-phy@00
prom_parse: Bad cell count for /qe@e0100000/mdio@2120/ethernet-phy@01

Well, I would say it's a bug to try to translate addresses accross such
a boundary. Thus the PHY enumeration code is bogus.

quoted

I also wonder why it hangs on the powerbook... Rutger, I would expect to
see that complaint warning with the reverted patch, what does it say ?

My Wallstreet (also based on Grackle) doesn't have the problem. Also can
you send me a tarball of /proc/device-tree ?

I don't have any of those machines, but it seems that older kernels
running on the Lombard emitted:

device-tree: Duplicate name in /cpus/PowerPC,750@0, renamed to "l2-cache#1"

That's a different matter.

messages*.  Experimenting with adding two chosen nodes (due to a prior
thread on this list**) results in a hung kernel on the 8360 also, so
perhaps they're related (and the kernel's tolerance to duplicate
entries has changed, which explains where I had seen the chosen node
being renamed).

but yeah, size-cells should be allowed to be 0 (even address-cells) and
it may be the case that the Lombard needs some fixup code.

Ben.

Kim Phillips writes:

but yeah, size-cells should be allowed to be 0 (even address-cells) and
it may be the case that the Lombard needs some fixup code.

So it turns out that the nvram is under the via-pmu node on the
Lombard.  The via-pmu node has #size-cells == 0, which is correct
since things under the via-pmu aren't directly accessible.  The nvram
driver code relies on not being able to translate an address for the
nvram nodes on machines where the nvram isn't directly accessible.
That is, it looks for "nvram" nodes, and if it can translate the
address, assumes it can access the nvram directly.

So nothing is incorrect here except your patch. :)  I'll revert it.

Paul.

Kim Phillips writes:

quoted

In which circumstances are you trying to translate an address with no
size cell ?

for the enumerated PHYs. As the original commit comment states, I was
getting these messages:

prom_parse: Bad cell count for /qe@e0100000/mdio@2120/ethernet-phy@00
prom_parse: Bad cell count for /qe@e0100000/mdio@2120/ethernet-phy@01

Specifically, which of_address_to_resource or other call is producing
these error messages?

Paul.

On Thu, 26 Jul 2007 13:42:33 +1000
Paul Mackerras [off-list ref] wrote:

Kim Phillips writes:

quoted

quoted

In which circumstances are you trying to translate an address with no
size cell ?

for the enumerated PHYs. As the original commit comment states, I was
getting these messages:

prom_parse: Bad cell count for /qe@e0100000/mdio@2120/ethernet-phy@00
prom_parse: Bad cell count for /qe@e0100000/mdio@2120/ethernet-phy@01

Specifically, which of_address_to_resource or other call is producing
these error messages?

Turns out I mistakenly added an mdio type to the platform
of_platform_bus_probe scan list early on in my ucc phylib migration
work, and it went unnoticed. Please do a:

git-revert 3baee955953957be5496cd28e9c544d9db214262

to remove "[POWERPC] Add 'mdio' to bus scan id list for platforms with
QE UEC" (in addition to the one you've already reverted).  Reverting
both these commits eliminates the prom_parse badness messages on the
MPC8360.

Thanks, and sorry,

Kim

p.s. should the stable team be notified to fix 2.6.22 for
Lombard-nvram-style machines?

On Thu, 2007-07-26 at 16:29 -0500, Kim Phillips wrote:

p.s. should the stable team be notified to fix 2.6.22 for
Lombard-nvram-style machines? 

Yes, definitely.

Cheers,
Ben.

Kim

p.s. should the stable team be notified to fix 2.6.22 for
Lombard-nvram-style machines?

Logically, yes. 

Practically it does not matter that much it seems. I've got the
feeling the Lombard-users-group-size is about one person which is
going to drop to zero if he doesn't get any further in being able to
use _any_ PCMCIA card in his machine ;-)

For example, PCMCIA (non-cardbus) does not work on Lombard since
~2.6.12 (2 years old bug instantly crashing the kernel!) according to
own experiences, Google and own git-bisecting down to 2.6.13,
compiling and running different kernels. 2.6.12 appears to require the
'old-style' PCMCIA tools, which I do not have installed and is
therefore impossible for me to test.

Links:
  2.6.12 works with PCMCIA on Lombard:
    http://www.mascanc.net/~vieri/gnumela.html
  2.6.13 dead
    (checked with git)
  2.6.15 dead (Lombard PCMCIA problems in FC5):
    http://forums.fedoraforum.org/archive/index.php/t-110657.html
  2.6.18 dead, 2.6.12 works:
    http://lists.infradead.org/pipermail/linux-pcmcia/2006-October/004051.html
  2.6.19 dead (own bug report):
    http://ozlabs.org/pipermail/linuxppc-dev/2006-November/028617.html
  2.6.20 dead:
    http://lists.infradead.org/pipermail/linux-pcmcia/2007-April/004500.html
  2.6.22 dead (own bug report #2):
    http://ozlabs.org/pipermail/linuxppc-dev/2007-July/039863.html

The initial reason to bisect to the now-reverting patch was to get a
working Lombard. I'd like to get this working or to help out in any
way, but I don't know how to proceed...

-- 
Rutger Nijlunsing ---------------------------------- eludias ed dse.nl
never attribute to a conspiracy which can be explained by incompetence
----------------------------------------------------------------------

On Sat, 2007-07-28 at 00:11 +0200, Rutger Nijlunsing wrote:

quoted

Kim

p.s. should the stable team be notified to fix 2.6.22 for
Lombard-nvram-style machines?

Logically, yes. 

Practically it does not matter that much it seems. I've got the
feeling the Lombard-users-group-size is about one person which is
going to drop to zero if he doesn't get any further in being able to
use _any_ PCMCIA card in his machine ;-)

Two ! Paulus has one :-) Though I'm not sure he uses it often nowadays.

For example, PCMCIA (non-cardbus) does not work on Lombard since
~2.6.12 (2 years old bug instantly crashing the kernel!) according to
own experiences, Google and own git-bisecting down to 2.6.13,
compiling and running different kernels. 2.6.12 appears to require the
'old-style' PCMCIA tools, which I do not have installed and is
therefore impossible for me to test.

Hrm. If Paul brings his Lombard to work next week, I can have a look.

Cheers,
Ben.

On Sat, 28 Jul 2007 08:26:47 +1000
Benjamin Herrenschmidt [off-list ref] wrote:

On Sat, 2007-07-28 at 00:11 +0200, Rutger Nijlunsing wrote:

quoted

quoted

Kim

p.s. should the stable team be notified to fix 2.6.22 for
Lombard-nvram-style machines?

Logically, yes. 

Two ! Paulus has one :-) Though I'm not sure he uses it often nowadays.

I sent the two revert requests to the stable team.

Kim