pci_proc_init: proc_dir_entry '00' already registered
Current Linus tree gives this new warning during bootup: +proc_dir_entry '00' already registered +Call Trace: +[c0007b0dfba0] [c000e4b0] .show_stack+0x70/0x1bc (unreliable) +[c0007b0dfc50] [c00f2714] .proc_register+0x130/0x210 +[c0007b0dfd00] [c00f299c] .proc_mkdir_mode+0x40/0x70 +[c0007b0dfd80] [c0276ed8] .pci_proc_attach_device+0xac/0x144 +[c0007b0dfe20] [c05bdb3c] .pci_proc_init+0x74/0xac +[c0007b0dfea0] [c05a27ac] .kernel_init+0x1d0/0x394 +[c0007b0dff90] [c001e258] .kernel_thread+0x4c/0x68 Its a dualcore G5. DART table allocated at: c0007f00 Using PowerMac machine description Page orders: linear mapping = 24, virtual = 12, io = 12 Found initrd at 0xc130:0xc1559c00 Found U4 memory controller & host bridge @ 0xf800 revision: 0x42 Mapped at 0xd8008000 Found a Shasta mac-io controller, rev: 0, mapped at 0xd80080041000 PowerMac motherboard: PowerMac G5 Dual Core DART IOMMU initialized for U4 type chipset console [udbg0] enabled CPU maps initialized for 1 thread per core (thread shift is 0) Starting Linux PPC64 #221 SMP Sun Feb 10 10:50:00 CET 2008 - ppc64_pft_size= 0x0 physicalMemorySize= 0x8000 htab_address = 0xc0007c00 htab_hash_mask= 0x3 - Linux version 2.6.24-g5-0-g25f6663 ([EMAIL PROTECTED]) (gcc version 4.1.0 (SUSE Linux)) #221 SMP Sun Feb 10 10:50:00 CET 2008 [boot]0012 Setup Arch Entering add_active_range(0, 0, 524288) 0 entries of 256 used Found U4-PCIE PCI host bridge. Firmware bus number: 0->255 PCI host bridge /[EMAIL PROTECTED],f000 ranges: MEM 0xf100..0xf1ff -> 0xf100 IO 0xf000..0xf07f -> 0x MEM 0x9000..0xafff -> 0x9000 Can't get bus-range for /[EMAIL PROTECTED],f200, assume bus 0 Found U3-HT PCI host bridge. Firmware bus number: 0->239 PCI host bridge /[EMAIL PROTECTED],f200 (primary) ranges: SMU: Driver 0.7 (c) 2005 Benjamin Herrenschmidt, IBM Corp. nvram: Checking bank 0... nvram: gen0=208, gen1=209 nvram: Active bank is: 1 nvram: OF partition at 0x410 nvram: XP partition at 0x1020 nvram: NR partition at 0x1120 Top of RAM: 0x8000, Total RAM: 0x8000 Memory hole size: 0MB Zone PFN ranges: DMA 0 -> 524288 Normal 524288 -> 524288 Movable zone start PFN for each node early_node_map[1] active PFN ranges 0:0 -> 524288 On node 0 totalpages: 524288 DMA zone: 7168 pages used for memmap DMA zone: 0 pages reserved DMA zone: 517120 pages, LIFO batch:31 Normal zone: 0 pages used for memmap Movable zone: 0 pages used for memmap [boot]0015 Setup Done Built 1 zonelists in Zone order, mobility grouping on. Total pages: 517120 Kernel command line: root=UUID=a77c3a2a-dd4a-4cf6-8c74-287c49897b10 sysrq=1 quiet video=nvidiafb:[EMAIL PROTECTED],bpp:16 panic=12 mpic: Setting up MPIC " MPIC 1 " version 1.2 at f804, max 4 CPUs mpic: ISU size: 124, shift: 7, mask: 7f mpic: Initializing for 124 sources mpic: Setting up HT PICs workarounds for U3/U4 mpic: - HT:07.0 [0x90] vendor 106b device 0053 has 86 irqs PID hash table entries: 4096 (order: 12, 32768 bytes) time_init: decrementer frequency = 33.33 MHz time_init: processor frequency = 2300.00 MHz clocksource: timebase mult[781] shift[22] registered clockevent: decrementer mult[888] shift[16] cpu[0] Console: colour dummy device 80x25 console handover: boot [udbg0] -> real [tty0] Dentry cache hash table entries: 262144 (order: 9, 2097152 bytes) Inode-cache hash table entries: 131072 (order: 8, 1048576 bytes) Memory: 2005248k/2097152k available (5984k kernel code, 91208k reserved, 940k data, 489k bss, 216k init) Calibrating delay loop... 66.56 BogoMIPS (lpj=332800) Mount-cache hash table entries: 256 device-tree: Duplicate name in /[EMAIL PROTECTED],f200/[EMAIL PROTECTED]/[EMAIL PROTECTED]/[EMAIL PROTECTED], renamed to "[EMAIL PROTECTED]" PowerMac SMP probe found 2 cpus KeyWest i2c @0xf8001003 irq 16 /[EMAIL PROTECTED],f800/[EMAIL PROTECTED] channel 1 bus /[EMAIL PROTECTED],f800/[EMAIL PROTECTED]/[EMAIL PROTECTED] KeyWest i2c @0x80018000 irq 27 /[EMAIL PROTECTED],f200/[EMAIL PROTECTED]/[EMAIL PROTECTED]/[EMAIL PROTECTED] channel 0 bus /[EMAIL PROTECTED],f200/[EMAIL PROTECTED]/[EMAIL PROTECTED]/[EMAIL PROTECTED]/[EMAIL PROTECTED] channel 0 bus /[EMAIL PROTECTED],f200/[EMAIL PROTECTED]/[EMAIL PROTECTED]/[EMAIL PROTECTED]/[EMAIL PROTECTED] SMU i2c /[EMAIL PROTECTED],0/[EMAIL PROTECTED] channel b bus /[EMAIL PROTECTED],0/[EMAIL PROTECTED]/[EMAIL PROTECTED] channel e bus /[EMAIL PROTECTED],0/[EMAIL PROTECTED]/[EMAIL PROTECTED] Processor timebase sync using platform function mpic: requesting IPIs ... Processor 1 found.
Re: pci_proc_init: proc_dir_entry '00' already registered
On Sun, Feb 10, 2008 at 11:07:57AM +0100, Olaf Hering wrote: > Current Linus tree gives this new warning during bootup: > > +proc_dir_entry '00' already registered > +Call Trace: > +[c0007b0dfba0] [c000e4b0] .show_stack+0x70/0x1bc (unreliable) > +[c0007b0dfc50] [c00f2714] .proc_register+0x130/0x210 > +[c0007b0dfd00] [c00f299c] .proc_mkdir_mode+0x40/0x70 > +[c0007b0dfd80] [c0276ed8] .pci_proc_attach_device+0xac/0x144 > +[c0007b0dfe20] [c05bdb3c] .pci_proc_init+0x74/0xac > +[c0007b0dfea0] [c05a27ac] .kernel_init+0x1d0/0x394 > +[c0007b0dff90] [c001e258] .kernel_thread+0x4c/0x68 Can you insert dump_stack() when '00' is registered, not just second time? ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] PPC440EP Interrupt Triggering and Level Settings
From: Wolfgang Ocker <[EMAIL PROTECTED]>
Corrected IRQ triggering and level settings according to latest revision
of the 440EP User Manual (rev 1.24 nov 16, 2007).
The incorrect settings might cause a failure of the network if both
onchip ethernet ports are under heavy load.
Signed-off-by: Wolfgang Ocker <[EMAIL PROTECTED]>
---
--- linux-2.6.24/arch/ppc/platforms/4xx/ibm440ep.c.irq-trig 2008-01-24
23:58:37.0 +0100
+++ linux-2.6.24/arch/ppc/platforms/4xx/ibm440ep.c 2008-02-10
19:43:32.0 +0100
@@ -172,11 +172,11 @@
/* Polarity and triggering settings for internal interrupt sources */
struct ppc4xx_uic_settings ppc4xx_core_uic_cfg[] __initdata = {
{ .polarity = 0xffbffe03,
- .triggering = 0xfe00,
+ .triggering = 0x,
.ext_irq_mask = 0x01fc, /* IRQ0 - IRQ6 */
},
- { .polarity = 0xc6ef,
- .triggering = 0xc7ff,
+ { .polarity = 0xc6af,
+ .triggering = 0x06000140,
.ext_irq_mask = 0x3800, /* IRQ7 - IRQ9 */
},
};
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 1/8] arch/ppc: Use FIELD_SIZEOF
From: Julia Lawall <[EMAIL PROTECTED]>
Robert P.J. Day proposed to use the macro FIELD_SIZEOF in replace of code
that matches its definition.
The modification was made using the following semantic patch
(http://www.emn.fr/x-info/coccinelle/)
//
@haskernel@
@@
#include
@depends on haskernel@
type t;
identifier f;
@@
- (sizeof(((t*)0)->f))
+ FIELD_SIZEOF(t, f)
@depends on haskernel@
type t;
identifier f;
@@
- sizeof(((t*)0)->f)
+ FIELD_SIZEOF(t, f)
//
Signed-off-by: Julia Lawall <[EMAIL PROTECTED]>
---
diff -u -p a/arch/ppc/8xx_io/commproc.c b/arch/ppc/8xx_io/commproc.c
--- a/arch/ppc/8xx_io/commproc.c 2008-02-02 15:28:16.0 +0100
+++ b/arch/ppc/8xx_io/commproc.c 2008-02-10 17:36:23.0 +0100
@@ -43,7 +43,7 @@
({ \
u32 offset = offsetof(immap_t, member); \
void *addr = ioremap (IMAP_ADDR + offset, \
- sizeof( ((immap_t*)0)->member)); \
+ FIELD_SIZEOF(immap_t, member)); \
addr; \
})
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Could the DTS experts look at this?
On Fri, Feb 08, 2008 at 06:30:56PM -0500, Sean MacLennan wrote:
> The Rev B warp is moving to a 4M NOR / 256M NAND flash setup from the
> current 64M NOR / 64M NAND. I would like to keep support for the 64M NOR
> so I modified the boot code to be a bit more dynamic. Here is the new
> NOR parition layout in the DTS:
>
> [EMAIL PROTECTED],0 {
> compatible = "amd,s29gl512n", "cfi-flash";
> bank-width = <2>;
> reg = <0 0 400>;
> #address-cells = <1>;
> #size-cells = <1>;
> [EMAIL PROTECTED] {
> label = "fpga";
> reg = <30 4>;
> };
> [EMAIL PROTECTED] {
> label = "env";
> reg = <34 4>;
> };
> [EMAIL PROTECTED] {
> label = "u-boot";
> reg = <38 8>;
> };
> };
>
> Yes, the top of the NOR will be empty. Here is the code from
> cuboot-warp.c to handle fixups for the 64M flash:
>
> static void warp_fixup_one_nor(u32 from, u32 to)
> {
> void *devp;
> char name[40];
> u32 v[2];
>
> sprintf(name, "/plb/opb/ebc/[EMAIL PROTECTED],0/[EMAIL PROTECTED]",
> from);
>
> devp = finddevice(name);
> if (!devp) return;
>
> if (getprop(devp, "reg", v, sizeof(v)) == sizeof(v)) {
> v[0] = to;
> setprop(devp, "reg", v, sizeof(v));
>
> printf("NOR 64M fixup %x -> %x\n", from, to);
> }
> }
>
>
> static void warp_fixups(void)
> {
> unsigned long sysclk = 6600;
>
> ibm440ep_fixup_clocks(sysclk, 11059200, 5000);
> ibm4xx_sdram_fixup_memsize();
> ibm4xx_fixup_ebc_ranges("/plb/opb/ebc");
> dt_fixup_mac_addresses(&bd.bi_enetaddr);
>
> /* Fixup for 64M flash on Rev A boards. */
> if(bd.bi_flashsize == 0x400) {
> warp_fixup_one_nor(0x30, 0x3f0);
> warp_fixup_one_nor(0x34, 0x3f4);
> warp_fixup_one_nor(0x38, 0x3f8);
> }
> }
This doesn't seem right. warp_fixup_one_nor() changes only the
partition's offset, so you're not changing the size of any
partitions. If you're not going to actually use any of the extra
flash space with 64M, I can't see why you'd bother moving around the
partitions you have.
> I have tested this with the 64M NOR, and it seems to work. However, are
> there going to be problems with the partition name not matching the reg
> address entry?
In practice, probably not. We already do a similar fixup on Ebony for
different flash layouts that won't leave the unit names correct. We
really should get this right - and the fdt_set_name() function that's
now in libfdt should make that possible, it just needs some wiring up
to use in the bootwrapper. That can come later, though, for now I
think applying your fixups without correcting the unit addresses is
adequate.
> If anybody has suggestions on better ways to do this, fire away.
>
> And looking at this code, and other board ports, why is sysclk a local
> variable and all the other numbers hardcoded in the args? I left it the
> same way as the others but it does look a bit strange.
I think this also came from Ebony. IIRC, the sysclk isn't strictly
speaking fixed, although it almost always has initialized value. The
point of the local variable was that I planned to replace the static
initialization with some sort of probing once I figured out the
details.
--
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] [POWERPC] Wire up new timerfd syscalls
Signed-off-by: Stephen Rothwell <[EMAIL PROTECTED]> --- include/asm-powerpc/systbl.h |4 +++- include/asm-powerpc/unistd.h |6 -- 2 files changed, 7 insertions(+), 3 deletions(-) Kernel built for ppc64_defconfig, pseries_defconfig, iseries_defconfig, cell_defconfig and pmac32_defconfig. The latter failed because check_media_bay is still undefined (i.e. for unrelated reasons). This has been tested on a pseries_defconfig kernel using the posted test program built for 64 and 32 bit. diff --git a/include/asm-powerpc/systbl.h b/include/asm-powerpc/systbl.h index e996521..ae7085c 100644 --- a/include/asm-powerpc/systbl.h +++ b/include/asm-powerpc/systbl.h @@ -309,8 +309,10 @@ SYSCALL_SPU(getcpu) COMPAT_SYS(epoll_pwait) COMPAT_SYS_SPU(utimensat) COMPAT_SYS_SPU(signalfd) -SYSCALL(ni_syscall) +SYSCALL_SPU(timerfd_create) SYSCALL_SPU(eventfd) COMPAT_SYS_SPU(sync_file_range2) COMPAT_SYS(fallocate) SYSCALL(subpage_prot) +COMPAT_SYS_SPU(timerfd_settime) +COMPAT_SYS_SPU(timerfd_gettime) diff --git a/include/asm-powerpc/unistd.h b/include/asm-powerpc/unistd.h index fedc4b8..ce91bb6 100644 --- a/include/asm-powerpc/unistd.h +++ b/include/asm-powerpc/unistd.h @@ -328,15 +328,17 @@ #define __NR_epoll_pwait 303 #define __NR_utimensat 304 #define __NR_signalfd 305 -#define __NR_timerfd 306 +#define __NR_timerfd_create306 #define __NR_eventfd 307 #define __NR_sync_file_range2 308 #define __NR_fallocate 309 #define __NR_subpage_prot 310 +#define __NR_timerfd_settime 311 +#define __NR_timerfd_gettime 312 #ifdef __KERNEL__ -#define __NR_syscalls 311 +#define __NR_syscalls 313 #define __NR__exit __NR_exit #define NR_syscalls__NR_syscalls -- 1.5.4 -- Cheers, Stephen Rothwell[EMAIL PROTECTED] http://www.canb.auug.org.au/~sfr/ ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Could the DTS experts look at this?
David Gibson wrote: > This doesn't seem right. warp_fixup_one_nor() changes only the > partition's offset, so you're not changing the size of any > partitions. If you're not going to actually use any of the extra > flash space with 64M, I can't see why you'd bother moving around the > partitions you have. > u-boot must be at the bottom of the flash. Also, for the 64M NOR flash you can put everything in the NOR flash, I just don't show the partitions. Booting from NOR is *much* faster than booting from NAND. > > In practice, probably not. We already do a similar fixup on Ebony for > different flash layouts that won't leave the unit names correct. We > really should get this right - and the fdt_set_name() function that's > now in libfdt should make that possible, it just needs some wiring up > to use in the bootwrapper. That can come later, though, for now I > think applying your fixups without correcting the unit addresses is > adequate. > > Ok. >> If anybody has suggestions on better ways to do this, fire away. >> >> And looking at this code, and other board ports, why is sysclk a local >> variable and all the other numbers hardcoded in the args? I left it the >> same way as the others but it does look a bit strange. >> > > I think this also came from Ebony. IIRC, the sysclk isn't strictly > speaking fixed, although it almost always has initialized value. The > point of the local variable was that I planned to replace the static > initialization with some sort of probing once I figured out the > details. > That makes sense. I don't think you can probe for the sysclk on the taco, so I may just put it as a constant to the function. Cheers, Sean ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Could the DTS experts look at this?
David Gibson wrote: > On Sun, Feb 10, 2008 at 09:40:19PM -0500, Sean MacLennan wrote: > >> David Gibson wrote: >> >>> This doesn't seem right. warp_fixup_one_nor() changes only the >>> partition's offset, so you're not changing the size of any >>> partitions. If you're not going to actually use any of the extra >>> flash space with 64M, I can't see why you'd bother moving around the >>> partitions you have. >>> >>> >> u-boot must be at the bottom of the flash. Also, for the 64M NOR flash >> you can put everything in the NOR flash, I just don't show the >> partitions. Booting from NOR is *much* faster than booting from >> NAND. >> > > Sorry, still not really following what's going on. Without worrying > about the dts formatting or fixup code, can you summarise what the two > flash maps look like? > > I guess what is confusing is that I am actually working with 3 flash maps right now, although there will only be one map in the final version. Map1: NOR: Kernel @ 0 Ramdisk User FPGA Env U-boot @ 63.5M Map 2: NOR: FPGA Env U-boot @ 63.5M NAND: Kernel @ 0 Ramdisk User Map 3: Same as Map 2 only 4M NOR rather than 64M, so u-boot @ 3.5M. The u-boot, env, and FPGA are anchored at the bottom of the flash. Kernel is anchored at the top. Everything else goes in the middle. The FPGA partition contains the FPGA image. The user partition contains a persistent JFFS2 file system. I don't use the user partition, so it doesn't show up in the map I sent. So map 1 was used until we got the NAND working. Map 2 is an interim solution until we get the 4M flash. Map 3 is the final version. Cheers, Sean ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [libfdt] RFC: Node iterators (v2)
On Thu, Feb 07, 2008 at 05:34:05PM -0600, Scott Wood wrote:
> David Gibson wrote:
> > And here's a revised version. This now also handles recursive
> > iteration and iteration across nodes without respect to depth. I've
> > removed the for_each() macros for the time being, because they were
> > making my brain hurt, but I'm still contemplating bringing them back.
> > Several libfdt functions are now implemented using the new iterator,
> > so this ends up as a code-size-reducing patch.
> >
> > I'm pretty happy with the basic outline of this now, although the
> > names and details might want a bit of polish still.
>
> Can we get this merged?
Well, I'm back from holidays now, so I will resume looking at this. I
hope we can merge it soon, yes.
> > +int _fdt_next_node(const void *fdt, int offset, int *depth)
> > +{
>
> This is a public function; why the underscore?
Well, because I still think of it as a low-level "only use if you
really know what you're doing" type function (which is what _ is
supposed to indicate; truly private functions don't need the fdt_
prefix at all).
--
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Could the DTS experts look at this?
On Sun, Feb 10, 2008 at 09:40:19PM -0500, Sean MacLennan wrote: > David Gibson wrote: > > This doesn't seem right. warp_fixup_one_nor() changes only the > > partition's offset, so you're not changing the size of any > > partitions. If you're not going to actually use any of the extra > > flash space with 64M, I can't see why you'd bother moving around the > > partitions you have. > > > u-boot must be at the bottom of the flash. Also, for the 64M NOR flash > you can put everything in the NOR flash, I just don't show the > partitions. Booting from NOR is *much* faster than booting from > NAND. Sorry, still not really following what's going on. Without worrying about the dts formatting or fixup code, can you summarise what the two flash maps look like? -- David Gibson| I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC][POWERPC] bootwrapper: Add a firmware-independent
On Friday, Feb 8, 2008 David Gibson wrote:
> On Fri, Feb 01, 2008 at 11:55:42PM -0700, Grant Likely wrote:
> From: Grant Likely
[snip]
>> +void platform_init(unsigned long r3, unsigned long r4, unsigned long r5,
>> + unsigned long r6, unsigned long r7)
>> +{
>> +const u32 *na, *ns, *reg, *timebase;
>> +u64 memsize64;
>> +int node, size, i;
>> +
>> +/* Allocate initial heap for probing the tree */
>> +simple_alloc_init(initial_heap, sizeof(initial_heap), 32, 64);
>> +
>> +/* Make sure FDT blob is sane */
>> +if (fdt_check_header(_dtb_start) != 0)
>> +fatal("Invalid device tree blob\n");
>
> I think most of these fatal()s are pretty pointless. This is
> platform_init(), so the console won't even have been initialized to
> actually print any of the messages. Precisely because this is
> simpleboot, in which every bit of information the wrapper has comes
> from teh device tree, if the provided blob is so bad as to fail these
> basic tests, we're totally stuffed anyway. It'll take a hardware
> debugger to track down, and I don't think the fatal()s will actually
> help much at that point.
My experience is the opposite: fatal is very useful even with a hardware
debugger. Since the code knows what is wrong, one only has to get the printf
assembly buffer out of the map and dump it out. Also, one can find which
function called fatal from the nia and/or lr. Much much easier than figuring
out what happend when the prcessor jumps into the middle of code because it
took an exception.
Also, one can patch in a debug output routine, possibly even in the
__zlib_init. Having the assertions is good.
That said, we should be conservative in calling something an error.
milton
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] PPC440EP Interrupt Triggering and Level Settings
On Sunday 10 February 2008, Wolfgang Ocker wrote: > From: Wolfgang Ocker <[EMAIL PROTECTED]> > > Corrected IRQ triggering and level settings according to latest revision > of the 440EP User Manual (rev 1.24 nov 16, 2007). > > The incorrect settings might cause a failure of the network if both > onchip ethernet ports are under heavy load. > > Signed-off-by: Wolfgang Ocker <[EMAIL PROTECTED]> Thanks, looks good. Acked-by: Stefan Roese <[EMAIL PROTECTED]> Best regards, Stefan ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
