This is on arch/powerpc.  I traced through the linked lists in 
resource.c.  Here is a partial list, with the addresses changed to 
single upper-case letters for readability.  Also "N" is a null pointer:

r=A p=N s=N c=K
r=K p=A s=M c=P
r=M p=A s=R c=N
r=R p=A s=B c=N
r=B p=B s=J c=B
r=J p=A s=C c=N
r=C p=A s=D c=N
r=D p=A s=E c=N
r=E p=A s=F c=N
r=F p=A s=G c=N
r=G p=A s=H c=N
r=H p=A s=N c=N
r=B p=B s=J c=B
r=J p=A s=C c=N
r=C p=A s=D c=N

r is the resource itself, p is the parent, s is the sibling, and c is 
the child.  As you can see, most nodes point back to parent "A", and 
have null children.  But one node, "B", points to itself both as parent 
and child.  I believe this is the problem, but I haven't confirmed that, 
nor have I determined how the list gets into this state.

    Steve


Stefan Roese wrote:
> Hi Steve,
>
> On Friday 09 November 2007, Steven A. Falco wrote:
>   
>> I am using the Denx 2.6.32 kernel, which does have powerpc/sequoia.
>> Xenomai is a real-time kernel built on Adeos/Ipipe.  I'll dig into it
>> further.
>>     
>
> Is this arch/ppc or arch/powerpc? I remember fixing this a while ago in 
> arch/ppc:
>
> commit 67a35ce785b1d11d09bf528c166ea26d489a4bd6
> Author: Stefan Roese <sr@denx.de>
> Date:   Thu Aug 2 14:15:22 2007 +0200
>
>     ppc: Fix problem with recursive NDFC platform_device resource management
>
>     This change fixes a problem with a resursive platform_device resource
>     management of the AMCC 4xx NDFC. Without this fix a "cat /proc/iomem"
>     leads to an infinite loop of printing the "ndfc-nand.0" resource.
>
>     Signed-off-by: Stefan Roese <sr@denx.de>
>
> Best regards,
> Stefan
>
>