PPC440EPx on Sequoia: /proc/iomem acts weird

PPC440EPx on Sequoia: /proc/iomem acts weird

[Steven A. Falco]

If I cat /proc/iomem on a Sequoia board, it never stops printing.  Here 
are the first 10 lines:

bash-3.00# head -10 /proc/iomem
e0000100-e000017f : usb
  e0000100-e000017f : musbhsfc_udc
e0000300-e000038f : ehci_hcd
180000000-18fffffff : /plb/pci@1eec00000
          1d0000000-1d0001fff : ndfc
          1d0000000-1d0001fff : ndfc
          1d0000000-1d0001fff : ndfc
          1d0000000-1d0001fff : ndfc
          1d0000000-1d0001fff : ndfc
          1d0000000-1d0001fff : ndfc

Basically, the last line (regarding the nand flash) keeps repeating 
"forever".

Is anyone else seeing this behavior?  My kernel is 2.6.23 with Xenomai 
patched in.

    Steve

Re: PPC440EPx on Sequoia: /proc/iomem acts weird

[Josh Boyer]

On Fri, 09 Nov 2007 13:30:03 -0500
"Steven A. Falco" <sfalco@harris.com> wrote:

> If I cat /proc/iomem on a Sequoia board, it never stops printing.  Here 
> are the first 10 lines:
> 
> bash-3.00# head -10 /proc/iomem
> e0000100-e000017f : usb
>   e0000100-e000017f : musbhsfc_udc
> e0000300-e000038f : ehci_hcd
> 180000000-18fffffff : /plb/pci@1eec00000
>           1d0000000-1d0001fff : ndfc
>           1d0000000-1d0001fff : ndfc
>           1d0000000-1d0001fff : ndfc
>           1d0000000-1d0001fff : ndfc
>           1d0000000-1d0001fff : ndfc
>           1d0000000-1d0001fff : ndfc
> 
> Basically, the last line (regarding the nand flash) keeps repeating 
> "forever".
> 
> Is anyone else seeing this behavior?  My kernel is 2.6.23 with Xenomai 
> patched in.

Erm.. 2.6.23?  There is no Sequoia support in arch/ppc or arch/powerpc
for 2.6.23 in the official trees.  What is Xenomai?  You should
probably talk to them.

josh

Re: PPC440EPx on Sequoia: /proc/iomem acts weird

[Steven A. Falco]

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

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.

    Steve


Josh Boyer wrote:
> On Fri, 09 Nov 2007 13:30:03 -0500
> "Steven A. Falco" <sfalco@harris.com> wrote:
>
>   
>> If I cat /proc/iomem on a Sequoia board, it never stops printing.  Here 
>> are the first 10 lines:
>>
>> bash-3.00# head -10 /proc/iomem
>> e0000100-e000017f : usb
>>   e0000100-e000017f : musbhsfc_udc
>> e0000300-e000038f : ehci_hcd
>> 180000000-18fffffff : /plb/pci@1eec00000
>>           1d0000000-1d0001fff : ndfc
>>           1d0000000-1d0001fff : ndfc
>>           1d0000000-1d0001fff : ndfc
>>           1d0000000-1d0001fff : ndfc
>>           1d0000000-1d0001fff : ndfc
>>           1d0000000-1d0001fff : ndfc
>>
>> Basically, the last line (regarding the nand flash) keeps repeating 
>> "forever".
>>
>> Is anyone else seeing this behavior?  My kernel is 2.6.23 with Xenomai 
>> patched in.
>>     
>
> Erm.. 2.6.23?  There is no Sequoia support in arch/ppc or arch/powerpc
> for 2.6.23 in the official trees.  What is Xenomai?  You should
> probably talk to them.
>
> josh
>
>   

[-- Attachment #2: Type: text/html, Size: 1626 bytes --]

Re: PPC440EPx on Sequoia: /proc/iomem acts weird

[Stefan Roese]

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

Re: PPC440EPx on Sequoia: /proc/iomem acts weird

[Steven A. Falco]

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

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

[-- Attachment #2: Type: text/html, Size: 2259 bytes --]

Re: PPC440EPx on Sequoia: /proc/iomem acts weird

[Steven A. Falco]

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

First I will say that I don't understand resources well enough to 
suggest a fix.  But I have done a little poking around.  In file 
arch/powerpc/platforms/44x/ppc4xx-nand.c I see one "struct resource", 
which is referenced by two "struct platform_device" items (ndfc_dev and 
nand_dev).

In routine ppc4xx_setup_nand_node() we have two calls to 
platform_device_register():

    platform_device_register(&ndfc_dev);
    platform_device_register(&nand_dev);

If I comment out the second one, then there is no loop in the resource 
tree, and I can cat /proc/iomem just fine.  If both calls are present, 
then cat /proc/iomem loops forever.

So, just a wild guess - should there be two "struct resource"s, one for 
each platform_device, or is there some other way to break the loop in 
the tree?

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

[-- Attachment #2: Type: text/html, Size: 2231 bytes --]