PPC440EPx on Sequoia: /proc/iomem acts weird
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 : ndfcBasically, 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
Quoted 15 lines · On Fri, 09 Nov 2007 13:30:03 -0500 "Steven A. Falco" <[email protected]> wrote:
If I cat
/proc/iomemon 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@1eec000001d0000000-1d0001fff : ndfc 1d0000000-1d0001fff : ndfc 1d0000000-1d0001fff : ndfc 1d0000000-1d0001fff : ndfc 1d0000000-1d0001fff : ndfc 1d0000000-1d0001fff : ndfc
Quoted 5 lines
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
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
Quoted 30 lines · Josh Boyer
Quoted 14 lines · On Fri, 09 Nov 2007 13:30:03 -0500 "Steven A. Falco" <[email protected]> wrote:
If I cat
/proc/iomemon 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@1eec000001d0000000-1d0001fff : ndfc 1d0000000-1d0001fff : ndfc 1d0000000-1d0001fff : ndfc 1d0000000-1d0001fff : ndfc 1d0000000-1d0001fff : ndfc 1d0000000-1d0001fff : ndfcQuoted 4 lines
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/ppcorarch/powerpcfor 2.6.23 in the official trees. What is Xenomai? You should probably talk to them.josh
Hi Steve,
Quoted 3 lines · Steven A. Falco
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 <[email protected]> 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.
Best regards,
Stefan
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
Quoted 27 lines · Stefan Roese
Hi Steve,
Quoted 4 lines · Steven A. Falco
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/ppcorarch/powerpc? I remember fixing this a while ago inarch/ppc:commit
67a35ce785b1d11d09bf528c166ea26d489a4bd6Author: Stefan Roese <[email protected]> Date: Thu Aug 2 14:15:22 2007 +0200ppc: Fix problem with recursive NDFC
platform_deviceresource managementThis change fixes a problem with a resursive
platform_deviceresource 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 <[email protected]>Best regards,
Stefan
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
Quoted 27 lines · Stefan Roese
Hi Steve,
Quoted 4 lines · Steven A. Falco
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/ppcorarch/powerpc? I remember fixing this a while ago inarch/ppc:commit
67a35ce785b1d11d09bf528c166ea26d489a4bd6Author: Stefan Roese <[email protected]> Date: Thu Aug 2 14:15:22 2007 +0200ppc: Fix problem with recursive NDFC
platform_deviceresource managementThis change fixes a problem with a resursive
platform_deviceresource 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 <[email protected]>Best regards,
Stefan