Re: [PATCH] irq: move some interrupt arch_* functions into struct irq_chip.
On Wed, 2010-03-10 at 10:55 +, i...@hellion.org.uk wrote: > > arch_init_chip_data cannot be moved into struct irq_chip at this time > because irq_desc->chip is not known at the time the irq_desc is > setup. For now rename arch_init_chip_data to arch_init_irq_desc (for > PowerPC, the only other user, whose usage better matches the new name) > and on x86 convert arch_init_chip_data to ioapic_init_chip_data and > call this whenever the IO APIC code allocates a new IRQ. One idea I had to improve this was to add a struct irq_chip * as a parameter to irq_to_desc_alloc_node. The new parameter potentially could be NULL for current behaviour. Does that sound like a reasonable approach? Ian. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] irq: move some interrupt arch_* functions into struct irq_chip.
On Wed, Mar 10, 2010 at 2:55 AM, wrote:
> From: Ian Campbell
>
> Move arch_init_copy_chip_data and arch_free_chip_data into function
> pointers in struct irq_chip since they operate on irq_desc->chip_data.
>
> arch_init_chip_data cannot be moved into struct irq_chip at this time
> because irq_desc->chip is not known at the time the irq_desc is
> setup. For now rename arch_init_chip_data to arch_init_irq_desc (for
> PowerPC, the only other user, whose usage better matches the new name)
> and on x86 convert arch_init_chip_data to ioapic_init_chip_data and
> call this whenever the IO APIC code allocates a new IRQ.
>
> I've retained the chip_data behaviour for uv_irq although it isn't
> clear to me if these interrupt types support migration or how closely
> related to the APIC modes they really are. If it weren't for this the
> ioapic_{init,copy,free}_chip_data functions could be static to
> io_apic.c.
>
> I've tested by booting on a 64 bit system, but it's not clear to me
> what actions I need to take to actually exercise some of these code
> paths.
>
can you just add another pointer field in irq_desc?
some kind of *irq_info etc.
YH
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] irq: move some interrupt arch_* functions into struct irq_chip.
From: Ian Campbell
Move arch_init_copy_chip_data and arch_free_chip_data into function
pointers in struct irq_chip since they operate on irq_desc->chip_data.
arch_init_chip_data cannot be moved into struct irq_chip at this time
because irq_desc->chip is not known at the time the irq_desc is
setup. For now rename arch_init_chip_data to arch_init_irq_desc (for
PowerPC, the only other user, whose usage better matches the new name)
and on x86 convert arch_init_chip_data to ioapic_init_chip_data and
call this whenever the IO APIC code allocates a new IRQ.
I've retained the chip_data behaviour for uv_irq although it isn't
clear to me if these interrupt types support migration or how closely
related to the APIC modes they really are. If it weren't for this the
ioapic_{init,copy,free}_chip_data functions could be static to
io_apic.c.
I've tested by booting on a 64 bit system, but it's not clear to me
what actions I need to take to actually exercise some of these code
paths.
Signed-off-by: Ian Campbell
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: H. Peter Anvin
Cc: Eric W. Biederman
Cc: Yinghai Lu
Cc: Jeremy Fitzhardinge
Cc: Benjamin Herrenschmidt
Cc: Paul Mackerras
Cc: x...@kernel.org
Cc: linuxppc-...@ozlabs.org
Cc: linux-ker...@vger.kernel.org
---
arch/powerpc/kernel/irq.c |2 +-
arch/x86/include/asm/hw_irq.h | 11 +++-
arch/x86/kernel/apic/io_apic.c | 58 +---
arch/x86/kernel/uv_irq.c |5 +++
include/linux/interrupt.h |2 +-
include/linux/irq.h| 12 +---
kernel/irq/handle.c|2 +-
kernel/irq/numa_migrate.c | 12 +++-
kernel/softirq.c |3 +-
9 files changed, 91 insertions(+), 16 deletions(-)
diff --git a/arch/powerpc/kernel/irq.c b/arch/powerpc/kernel/irq.c
index 64f6f20..002d87f 100644
--- a/arch/powerpc/kernel/irq.c
+++ b/arch/powerpc/kernel/irq.c
@@ -1088,7 +1088,7 @@ int arch_early_irq_init(void)
return 0;
}
-int arch_init_chip_data(struct irq_desc *desc, int node)
+int arch_init_irq_desc(struct irq_desc *desc, int node)
{
desc->status |= IRQ_NOREQUEST;
return 0;
diff --git a/arch/x86/include/asm/hw_irq.h b/arch/x86/include/asm/hw_irq.h
index 0642186..b9d7310 100644
--- a/arch/x86/include/asm/hw_irq.h
+++ b/arch/x86/include/asm/hw_irq.h
@@ -20,9 +20,9 @@
#include
#include
#include
+#include
#include
-#include
#include
/* Interrupt handlers registered during init_IRQ */
@@ -61,6 +61,15 @@ extern void init_VISWS_APIC_irqs(void);
extern void setup_IO_APIC(void);
extern void disable_IO_APIC(void);
+extern int ioapic_init_chip_data(struct irq_desc *desc, int node);
+
+#ifdef CONFIG_SPARSE_IRQ
+extern void ioapic_copy_chip_data(struct irq_desc *old_desc,
+ struct irq_desc *desc, int node);
+extern void ioapic_free_chip_data(struct irq_desc *old_desc,
+ struct irq_desc *desc);
+#endif
+
struct io_apic_irq_attr {
int ioapic;
int ioapic_pin;
diff --git a/arch/x86/kernel/apic/io_apic.c b/arch/x86/kernel/apic/io_apic.c
index a57d974..74d5d96 100644
--- a/arch/x86/kernel/apic/io_apic.c
+++ b/arch/x86/kernel/apic/io_apic.c
@@ -211,7 +211,7 @@ static struct ioapic_irq_cfg *get_one_free_irq_cfg(int node)
return cfg;
}
-int arch_init_chip_data(struct irq_desc *desc, int node)
+int ioapic_init_chip_data(struct irq_desc *desc, int node)
{
struct ioapic_irq_cfg *cfg;
@@ -289,8 +289,8 @@ static void free_irq_2_pin(struct ioapic_irq_cfg *old_cfg,
old_cfg->irq_2_pin = NULL;
}
-void arch_init_copy_chip_data(struct irq_desc *old_desc,
-struct irq_desc *desc, int node)
+void ioapic_copy_chip_data(struct irq_desc *old_desc,
+ struct irq_desc *desc, int node)
{
struct ioapic_irq_cfg *cfg;
struct ioapic_irq_cfg *old_cfg;
@@ -314,7 +314,7 @@ static void free_irq_cfg(struct ioapic_irq_cfg *old_cfg)
kfree(old_cfg);
}
-void arch_free_chip_data(struct irq_desc *old_desc, struct irq_desc *desc)
+void ioapic_free_chip_data(struct irq_desc *old_desc, struct irq_desc *desc)
{
struct ioapic_irq_cfg *old_cfg, *cfg;
@@ -338,6 +338,11 @@ struct ioapic_irq_cfg *ioapic_irq_cfg(unsigned int irq)
return irq < nr_irqs ? irq_cfgx + irq : NULL;
}
+int ioapic_init_chip_data(struct irq_desc *desc, int node)
+{
+ return 0;
+}
+
#endif
struct io_apic {
@@ -1526,6 +1531,7 @@ static void __init setup_IO_APIC_irqs(void)
printk(KERN_INFO "can not get irq_desc for %d\n", irq);
continue;
}
+ ioapic_init_chip_data(desc, node);
cfg = desc->chip_data;
add_pin_to_irq_node(cfg, node, apic_id, pin);
/*
@@ -1576,6 +1582,7 @@ void setup_IO_APIC_irq_extra(u32 gsi)
printk(KERN_INFO "can not get irq_desc for %d\n", irq
[PATCH v2] powerpc: export data from new hcall H_EM_GET_PARMS
Hi Ben,
I have cleaned up the code from the previous post:
http://lists.ozlabs.org/pipermail/linuxppc-dev/2010-February/080630.html
Changes from v1:
* Removed redundant return statements and rearranged code
Description:
A new hcall H_EM_GET_PARMS as been added to obtain power mode data
from the platform. This data can be used by user space administrative
tools for better power management.
The following patch add data from this new hcall into the lparcfg
driver and exports to user space along with other existing lpar data
in /proc/powerpc/lparcfg
Please review and include in powerpc -next tree.
Thanks,
Vaidy
---
powerpc: export data from new hcall H_EM_GET_PARMS
Add support for H_EM_GET_PARMS hcall that will return data
related to power modes from the platform. Export the data
directly to user space for administrative tools to interpret
and use.
cat /proc/powerpc/lparcfg will export power mode data
Signed-off-by: Vaidyanathan Srinivasan
---
arch/powerpc/include/asm/hvcall.h |1 +
arch/powerpc/kernel/lparcfg.c | 12 +++-
2 files changed, 12 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/include/asm/hvcall.h
b/arch/powerpc/include/asm/hvcall.h
index f027581..ebe7493 100644
--- a/arch/powerpc/include/asm/hvcall.h
+++ b/arch/powerpc/include/asm/hvcall.h
@@ -228,6 +228,7 @@
#define H_JOIN 0x298
#define H_VASI_STATE0x2A4
#define H_ENABLE_CRQ 0x2B0
+#define H_GET_EM_PARMS 0x2B8
#define H_SET_MPP 0x2D0
#define H_GET_MPP 0x2D4
#define MAX_HCALL_OPCODE H_GET_MPP
diff --git a/arch/powerpc/kernel/lparcfg.c b/arch/powerpc/kernel/lparcfg.c
index d09d1c6..ff698fb 100644
--- a/arch/powerpc/kernel/lparcfg.c
+++ b/arch/powerpc/kernel/lparcfg.c
@@ -37,7 +37,7 @@
#include
#include
-#define MODULE_VERS "1.8"
+#define MODULE_VERS "1.9"
#define MODULE_NAME "lparcfg"
/* #define LPARCFG_DEBUG */
@@ -486,6 +486,14 @@ static void splpar_dispatch_data(struct seq_file *m)
seq_printf(m, "dispatch_dispersions=%lu\n", dispatch_dispersions);
}
+static void parse_em_data(struct seq_file *m)
+{
+ unsigned long retbuf[PLPAR_HCALL_BUFSIZE];
+
+ if (plpar_hcall(H_GET_EM_PARMS, retbuf) == H_SUCCESS)
+ seq_printf(m, "power_mode_data=%016lx\n", retbuf[0]);
+}
+
static int pseries_lparcfg_data(struct seq_file *m, void *v)
{
int partition_potential_processors;
@@ -540,6 +548,8 @@ static int pseries_lparcfg_data(struct seq_file *m, void *v)
seq_printf(m, "slb_size=%d\n", mmu_slb_size);
+ parse_em_data(m);
+
return 0;
}
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] irq: move some interrupt arch_* functions into struct irq_chip.
On Wed, 2010-03-10 at 12:06 +, Yinghai Lu wrote:
> On Wed, Mar 10, 2010 at 2:55 AM, wrote:
> > From: Ian Campbell
> >
> > Move arch_init_copy_chip_data and arch_free_chip_data into function
> > pointers in struct irq_chip since they operate on irq_desc->chip_data.
> >
> > arch_init_chip_data cannot be moved into struct irq_chip at this time
> > because irq_desc->chip is not known at the time the irq_desc is
> > setup. For now rename arch_init_chip_data to arch_init_irq_desc (for
> > PowerPC, the only other user, whose usage better matches the new name)
> > and on x86 convert arch_init_chip_data to ioapic_init_chip_data and
> > call this whenever the IO APIC code allocates a new IRQ.
> >
> > I've retained the chip_data behaviour for uv_irq although it isn't
> > clear to me if these interrupt types support migration or how closely
> > related to the APIC modes they really are. If it weren't for this the
> > ioapic_{init,copy,free}_chip_data functions could be static to
> > io_apic.c.
> >
> > I've tested by booting on a 64 bit system, but it's not clear to me
> > what actions I need to take to actually exercise some of these code
> > paths.
> >
>
> can you just add another pointer field in irq_desc?
>
> some kind of *irq_info etc.
I think I don't understand what you are suggesting.
There is already a pointer for irq_chip specific use i.e.
irq_desc->chip_data. This patchset is just about ensuring that the field
really is available to any chip implementation rather than just assuming
it is always used for the acpi chip types (on x86 at least).
Does adding a second pointer with the same (intended?) semantics as the
existing one buy us anything?
Ian.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
mv643xx_eth broken again on pegasos2 G4
hi, mv643xx_eth driver seems to be broken (and very often there is a kernel panic too). Last working kernel is 2.6.31.2 here a dmesg from 2.6.32.9: memory = 1024MB; using 2048kB for hash table (at cfe0) Linux version 2.6.32.9 (r...@pegasos2) (gcc version 4.3.4 (CRUX PPC) (GCC) ) #1 PREEMPT Wed Mar 10 15:56:51 CET 2010 Found legacy serial port 0 for /p...@8000/i...@c/ser...@i2f8 port=2f8, taddr=fe0002f8, irq=0, clk=1843200, speed=0 bootconsole [udbg0] enabled chrp type = 6 [Genesi Pegasos] Pegasos l2cr : L2 cache was not active, activating PCI bus 0 controlled by /p...@8000 at 8000 PCI host bridge /p...@8000 (primary) ranges: IO 0xfe00..0xfe00 -> 0x MEM 0x8000..0xbfff -> 0x8000 PCI bus 0 controlled by /p...@c000 at c000 PCI host bridge /p...@c000 ranges: IO 0xf800..0xf800 -> 0x MEM 0xc000..0xdfff -> 0xc000 Top of RAM: 0x4000, Total RAM: 0x4000 Memory hole size: 0MB Zone PFN ranges: DMA 0x -> 0x0003 Normal 0x0003 -> 0x0003 HighMem 0x0003 -> 0x0004 Movable zone start PFN for each node early_node_map[1] active PFN ranges 0: 0x -> 0x0004 On node 0 totalpages: 262144 free_area_init_node: node 0, pgdat c045b65c, node_mem_map c0baf000 DMA zone: 1536 pages used for memmap DMA zone: 0 pages reserved DMA zone: 195072 pages, LIFO batch:31 HighMem zone: 512 pages used for memmap HighMem zone: 65024 pages, LIFO batch:15 Built 1 zonelists in Zone order, mobility grouping on. Total pages: 260096 Kernel command line: root=/dev/hda5 video=radeonfb:800x...@60 mv643xx_eth=no PID hash table entries: 4096 (order: 2, 16384 bytes) Dentry cache hash table entries: 131072 (order: 7, 524288 bytes) Inode-cache hash table entries: 65536 (order: 6, 262144 bytes) High memory: 262080k Memory: 1031700k/1048576k available (4268k kernel code, 16184k reserved, 236k da ta, 120k bss, 160k init) Kernel virtual memory layout: * 0xfffef000..0xf000 : fixmap * 0xff80..0xffc0 : highmem PTEs * 0xff7e..0xff80 : early ioremap * 0xf100..0xff7e : vmalloc & ioremap SLUB: Genslabs=13, HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1 Hierarchical RCU implementation. NR_IRQS:512 i8259 legacy interrupt controller initialized time_init: decrementer frequency = 33.33 MHz time_init: processor frequency = 999.90 MHz clocksource: timebase mult[781] shift[22] registered clockevent: decrementer mult[887] shift[32] cpu[0] Console: colour dummy device 80x25 console [tty0] enabled, bootconsole disabled Mount-cache hash table entries: 512 NET: Registered protocol family 16 PCI: Probing PCI hardware pci :00:01.0: reg 10 32bit mmio: [0x8000-0x87ff] pci :00:01.0: reg 14 io port: [0x1080-0x10ff] pci :00:01.0: supports D2 pci :00:01.0: PME# supported from D2 D3hot D3cold pci :00:01.0: PME# disabled pci :00:0c.1: reg 10 io port: [0x1000-0x1007] pci :00:0c.1: reg 14 io port: [0x100c-0x100f] pci :00:0c.1: reg 18 io port: [0x1010-0x1017] pci :00:0c.1: reg 1c io port: [0x101c-0x101f] pci :00:0c.1: reg 20 io port: [0x1020-0x102f] pci :00:0c.2: reg 20 io port: [0x1040-0x105f] pci :00:0c.3: reg 20 io port: [0x1060-0x107f] pci :00:0c.5: reg 10 io port: [0x1100-0x11ff] pci :00:0c.5: reg 14 io port: [0x1030-0x1033] pci :00:0c.5: reg 18 io port: [0x1034-0x1037] pci :00:0c.6: reg 10 io port: [0x1200-0x12ff] pci :00:0d.0: reg 10 io port: [0x1300-0x13ff] pci :00:0d.0: reg 14 32bit mmio: [0x8800-0x88ff] pci :00:0d.0: PME# supported from D0 D3hot D3cold pci :00:0d.0: PME# disabled pci 0001:01:08.0: reg 10 32bit mmio pref: [0xc000-0xc7ff] pci 0001:01:08.0: reg 14 io port: [0x1000-0x10ff] pci 0001:01:08.0: reg 18 32bit mmio: [0xc800-0xc800] pci 0001:01:08.0: reg 30 32bit mmio pref: [0xc802-0xc803] pci 0001:01:08.0: supports D1 D2 pci 0001:01:08.1: reg 10 32bit mmio pref: [0xd000-0xd7ff] pci 0001:01:08.1: reg 14 32bit mmio: [0xc801-0xc801] pci 0001:01:08.1: supports D1 D2 PCI :00 Cannot reserve Legacy IO [0x00-0xfff] pci_bus :00: resource 0 io: [0x00-0x] pci_bus :00: resource 1 mem: [0x8000-0xbfff] pci_bus 0001:01: resource 0 io: [0x-0x] pci_bus 0001:01: resource 1 mem: [0xc000-0xdfff] bio: create slab at 0 vgaarb: device added: PCI:0001:01:08.0,decodes=io+mem,owns=io+mem,locks=none vgaarb: loaded SCSI subsystem initialized Switching to clocksource timebase NET: Registered protocol family 2 IP route cache hash table entries: 32768 (order: 5, 131072 bytes) TCP established hash table entries: 131072 (order: 8, 1048576 bytes) TCP bind hash table entries: 65536 (order: 6, 262144 bytes) TCP: Hash tables configured (established 131072 bind 65536) TCP reno registered NET: Registered protoc
Re: mv643xx_eth broken again on pegasos2 G4
On Wed, Mar 10, 2010 at 04:14:41PM +0100, acrux wrote: > hi, > mv643xx_eth driver seems to be broken (and very often there is a kernel panic > too). > Last working kernel is 2.6.31.2 > > here a dmesg from 2.6.32.9: My Pegasos running a pristine 2.6.32 seems to disagree with you. [...] Linux version 2.6.32 (x...@yyy) (gcc version 4.3.2 (Debian 4.3.2-1.1) ) #129 Mon Jan 18 16:29:40 GMT 2010 Found legacy serial port 0 for /p...@8000/i...@c/ser...@i2f8 port=2f8, taddr=fe0002f8, irq=0, clk=1843200, speed=0 chrp type = 6 [Genesi Pegasos] [...] MV-643xx 10/100/1000 ethernet driver version 1.4 mv643xx_eth smi: probed net eth1: port 1 with MAC address 00:0b:2f:15:10:ef net eth1: configured with sram [...] This said I cannot go close to it right now to compile and test something newer. But I can connect to it through the network and it uses the mv643xx_eth port. The difference may be that mv643xx_eth is built-in and not modular. > MV-643xx 10/100/1000 ethernet driver version 1.4 > sysfs: cannot create duplicate filename '/class/mdio_bus/0' > [ cut here ] > Badness at fs/sysfs/dir.c:491 > NIP: c00dc568 LR: c00dc568 CTR: c00200ac > REGS: ef015c70 TRAP: 0700 Not tainted (2.6.32.9) > MSR: 00029032 CR: 22422488 XER: > TASK = ef082bc0[1011] 'modprobe' THREAD: ef014000 > GPR00: c00dc568 ef015d20 ef082bc0 0042 c04303f0 c04303f0 0001 > GPR08: 01430ee0 81f2ba43 10020a5c > GPR16: 100056bc 0003 4801f000 c0430120 > GPR24: 107fb560 107fb57c ef17fc48 0001 ffef ef015d48 ef108030 ef355000 > NIP [c00dc568] sysfs_add_one+0x7c/0xa0 > LR [c00dc568] sysfs_add_one+0x7c/0xa0 > Call Trace: > [ef015d20] [c00dc568] sysfs_add_one+0x7c/0xa0 (unreliable) > [ef015d40] [c00dd700] sysfs_do_create_link+0xf4/0x188 > [ef015d70] [c022ffbc] device_add+0x1a8/0x51c > [ef015db0] [c026be38] mdiobus_register+0xa0/0x1ac > [ef015de0] [f224d5dc] mv643xx_eth_shared_probe+0x140/0x3f8 [mv643xx_eth] > [ef015e00] [c0233dd0] platform_drv_probe+0x20/0x30 > [ef015e10] [c0232a4c] driver_probe_device+0xd4/0x1a8 > [ef015e30] [c0232b90] __driver_attach+0x70/0xa4 > [ef015e50] [c02320cc] bus_for_each_dev+0x5c/0xac > [ef015e80] [c023285c] driver_attach+0x24/0x34 > [ef015e90] [c0231910] bus_add_driver+0xb4/0x248 > [ef015eb0] [c0232f78] driver_register+0xd0/0x174 > [ef015ed0] [c023412c] platform_driver_register+0x6c/0x7c > [ef015ee0] [f2256024] mv643xx_eth_init_module+0x24/0x80 [mv643xx_eth] > [ef015f00] [c0003ee0] do_one_initcall+0x64/0x1f8 > [ef015f20] [c0054680] sys_init_module+0xe0/0x224 > [ef015f40] [c0013828] ret_from_syscall+0x0/0x38 > --- Exception: c01 at 0xff69720 > LR = 0x10004150 > Instruction dump: > 807d 7fe4fb78 4b51 3c80c03a 3884adb0 4bf3ce4d 809e0010 4bf3ce45 > 7c641b78 3c60c03b 38639868 48259099 <0fe0> 7fe3fb78 4bfaac0d 80010024 > mii_bus 0 failed to register > mv643xx_eth: probe of mv643xx_eth.0 failed with error -12 > Unable to handle kernel paging request for data at address 0x > Faulting instruction address: 0xf2250908 > Oops: Kernel access of bad area, sig: 11 [#1] > PREEMPT CHRP > Modules linked in: mv643xx_eth(+) via_rhine serio_raw parport firewire_core > NIP: f2250908 LR: f2250900 CTR: c0232574 > REGS: ef015d10 TRAP: 0300 Tainted: GW (2.6.32.9) > MSR: 9032 CR: 84422488 XER: 2000 > DAR: , DSISR: 4000 > TASK = ef082bc0[1011] 'modprobe' THREAD: ef014000 > GPR00: f22508f4 ef015dc0 ef082bc0 efb42300 efb42005 efb4214d > GPR08: 0001 2bfd0c6b c0232574 10020a5c > GPR16: 100056bc 0003 c0430230 > GPR24: c0430228 107fb57c efb42000 f22528c0 fff4 c04300d8 efb42300 > NIP [f2250908] mv643xx_eth_probe+0xac/0x620 [mv643xx_eth] > LR [f2250900] mv643xx_eth_probe+0xa4/0x620 [mv643xx_eth] > Call Trace: > [ef015dc0] [f22508f4] mv643xx_eth_probe+0x98/0x620 [mv643xx_eth] (unreliable) > [ef015e00] [c0233dd0] platform_drv_probe+0x20/0x30 > [ef015e10] [c0232a4c] driver_probe_device+0xd4/0x1a8 > [ef015e30] [c0232b90] __driver_attach+0x70/0xa4 > [ef015e50] [c02320cc] bus_for_each_dev+0x5c/0xac > [ef015e80] [c023285c] driver_attach+0x24/0x34 > [ef015e90] [c0231910] bus_add_driver+0xb4/0x248 > [ef015eb0] [c0232f78] driver_register+0xd0/0x174 > [ef015ed0] [c023412c] platform_driver_register+0x6c/0x7c > [ef015ee0] [f2256034] mv643xx_eth_init_module+0x34/0x80 [mv643xx_eth] > [ef015f00] [c0003ee0] do_one_initcall+0x64/0x1f8 > [ef015f20] [c0054680] sys_init_module+0xe0/0x224 > [ef015f40] [c0013828] ret_from_syscall+0x0/0x38 > --- Exception: c01 at 0xff69720 > LR = 0x10004150 > Instruction dump: > 7c7b1b79 41820528 3bfb0300 3a980008 7e83a378 7fe4fb78 48000dd1 807e > 38630008 480011b5 907b0300 813e0004 <8003> 5529502a 39290400 7c004a14 > ---[ end trace 1a9241f24ee15efc ]--- Gabriel ___ Linu
Re: [PATCH] irq: move some interrupt arch_* functions into struct irq_chip.
On Wed, 2010-03-10 at 17:18 +, Eric W. Biederman wrote: > Ian Campbell writes: > > > On Wed, 2010-03-10 at 10:55 +, i...@hellion.org.uk wrote: > >> > >> arch_init_chip_data cannot be moved into struct irq_chip at this time > >> because irq_desc->chip is not known at the time the irq_desc is > >> setup. For now rename arch_init_chip_data to arch_init_irq_desc (for > >> PowerPC, the only other user, whose usage better matches the new name) > >> and on x86 convert arch_init_chip_data to ioapic_init_chip_data and > >> call this whenever the IO APIC code allocates a new IRQ. > > > > One idea I had to improve this was to add a struct irq_chip * as a > > parameter to irq_to_desc_alloc_node. The new parameter potentially could > > be NULL for current behaviour. Does that sound like a reasonable > > approach? > > I don't follow why we have the restriction that irq_to_desc_alloc_node > must call arch_init_chip_data. Assuming that requirement to call > arch_init_chip_data > is valid, passing something into init_one_irq_desc seems appropriate. Yes, I suspect that could also be made to work. The lifecycle of the irq_desc and chip_data isn't really clear to me -- I guess once allocated an irq_desc never gets freed (at least currently)? The associated chip_data can be freed on migrate and replaced with a new one, but is not freed otherwise. My concern is that if the caller asks for an IRQ which already exists (is that valid?) then you will get that existing irq_desc back, including its existing chip_data, which potentially leaks the new one which was passed in. Or is it the case that the only way this could happen would be for legacy IRQs? In which case perhaps it is simply invalid to pass a new chip data in for such an IRQ. Ian. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] irq: move some interrupt arch_* functions into struct irq_chip.
Ian Campbell writes:
> On Wed, 2010-03-10 at 12:06 +, Yinghai Lu wrote:
>> On Wed, Mar 10, 2010 at 2:55 AM, wrote:
>> > From: Ian Campbell
>> >
>> > Move arch_init_copy_chip_data and arch_free_chip_data into function
>> > pointers in struct irq_chip since they operate on irq_desc->chip_data.
>> >
>> > arch_init_chip_data cannot be moved into struct irq_chip at this time
>> > because irq_desc->chip is not known at the time the irq_desc is
>> > setup. For now rename arch_init_chip_data to arch_init_irq_desc (for
>> > PowerPC, the only other user, whose usage better matches the new name)
>> > and on x86 convert arch_init_chip_data to ioapic_init_chip_data and
>> > call this whenever the IO APIC code allocates a new IRQ.
>> >
>> > I've retained the chip_data behaviour for uv_irq although it isn't
>> > clear to me if these interrupt types support migration or how closely
>> > related to the APIC modes they really are. If it weren't for this the
>> > ioapic_{init,copy,free}_chip_data functions could be static to
>> > io_apic.c.
>> >
>> > I've tested by booting on a 64 bit system, but it's not clear to me
>> > what actions I need to take to actually exercise some of these code
>> > paths.
>> >
>>
>> can you just add another pointer field in irq_desc?
>>
>> some kind of *irq_info etc.
>
> I think I don't understand what you are suggesting.
YH another field doesn't make much sense. Xen is a bizarre subarch
with an incompatible irq model. Xen simply needs the ability to
handle the entire lifetime of an irq_chip.
All we need between the Xen and the rest of x86 is a convention
so that we never manage the same irqs. At least for domU we are
in an either/or situation so I don't see even that being a problem.
> There is already a pointer for irq_chip specific use i.e.
> irq_desc->chip_data. This patchset is just about ensuring that the field
> really is available to any chip implementation rather than just assuming
> it is always used for the acpi chip types (on x86 at least).
Ian Xen in this sense is simply not x86. irq_cfg is not acpi or ioapic
or anything but x86 specific. It has everything to do with having a per
cpu vector table of 256 entries and architecturally receiving a vector
number when an interrupt is fired.
It totally makes sense for Xen to do something different because
architecturally it has a completely different irq subsystem.
At the same time let's not pretend that the reason for this is anything
except that Xen has a completely different notion of interrupt delivery
than the rest of x86 and so it is it's own bizarre subarch.
This is not a case where you simply need a driver because something is
a bit different but fits into the existing model.
So the best solution here seems to be a parameter that we pass into
irq_to_desc_alloc_node that does what is needed. The second best
would be to have arch_init_chip_data to call something like
platfrom_init_chip_data().But I think we can avoid that in
this case.
Eric
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] irq: move some interrupt arch_* functions into struct irq_chip.
On Wed, 2010-03-10 at 17:42 +, Eric W. Biederman wrote: > > > Ian Xen in this sense is simply not x86. irq_cfg is not acpi or > ioapic or anything but x86 specific. It has everything to do with > having a per cpu vector table of 256 entries and architecturally > receiving a vector number when an interrupt is fired. > > It totally makes sense for Xen to do something different because > architecturally it has a completely different irq subsystem. OK, so that sounds like you would like the same patchset but without the irq_cfg renaming? or potentially with renaming to x86_blah instead (I'll rework to your preference). Ian. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] irq: move some interrupt arch_* functions into struct irq_chip.
Ian Campbell writes: > On Wed, 2010-03-10 at 17:18 +, Eric W. Biederman wrote: >> Ian Campbell writes: >> >> > On Wed, 2010-03-10 at 10:55 +, i...@hellion.org.uk wrote: >> >> >> >> arch_init_chip_data cannot be moved into struct irq_chip at this time >> >> because irq_desc->chip is not known at the time the irq_desc is >> >> setup. For now rename arch_init_chip_data to arch_init_irq_desc (for >> >> PowerPC, the only other user, whose usage better matches the new name) >> >> and on x86 convert arch_init_chip_data to ioapic_init_chip_data and >> >> call this whenever the IO APIC code allocates a new IRQ. >> > >> > One idea I had to improve this was to add a struct irq_chip * as a >> > parameter to irq_to_desc_alloc_node. The new parameter potentially could >> > be NULL for current behaviour. Does that sound like a reasonable >> > approach? >> >> I don't follow why we have the restriction that irq_to_desc_alloc_node >> must call arch_init_chip_data. Assuming that requirement to call >> arch_init_chip_data >> is valid, passing something into init_one_irq_desc seems appropriate. > > Yes, I suspect that could also be made to work. > > The lifecycle of the irq_desc and chip_data isn't really clear to me -- > I guess once allocated an irq_desc never gets freed (at least > currently)? The associated chip_data can be freed on migrate and > replaced with a new one, but is not freed otherwise. Yes. That actually looks like a bug. > My concern is that if the caller asks for an IRQ which already exists > (is that valid?) then you will get that existing irq_desc back, > including its existing chip_data, which potentially leaks the new one > which was passed in. Or is it the case that the only way this could > happen would be for legacy IRQs? In which case perhaps it is simply > invalid to pass a new chip data in for such an IRQ. The only irqs that should be allocated/freed are probably the msi irqs as those are the only ones that dynamically come and go in the system. Unfortunately there appears to be a bigger mess here than first appeared. Eric ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] irq: move some interrupt arch_* functions into struct irq_chip.
Ian Campbell writes: > On Wed, 2010-03-10 at 17:42 +, Eric W. Biederman wrote: >> >> >> Ian Xen in this sense is simply not x86. irq_cfg is not acpi or >> ioapic or anything but x86 specific. It has everything to do with >> having a per cpu vector table of 256 entries and architecturally >> receiving a vector number when an interrupt is fired. >> >> It totally makes sense for Xen to do something different because >> architecturally it has a completely different irq subsystem. > > OK, so that sounds like you would like the same patchset but without the > irq_cfg renaming? or potentially with renaming to x86_blah instead (I'll > rework to your preference). Currently the renaming really makes it unclear what you are doing and for some reason the description of the renaming rubbed me the wrong way. Eric ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
5200B: BUG in 2.6.34-rc1-dirty while loading at24 driver
Hi all, not sure if this is the right place to ask: When I boot a custom 5200B (more or less Lite-based) board with Linus' git tree (2.6.34-rc1-dirty), I always get the following bug: [1.110693] i2c /dev entries driver [1.117285] mpc-i2c f0003d00.i2c: clock 375000 Hz (fdr=137) [1.123156] mpc-i2c f0003d00.i2c: timeout 100 us [1.146528] mpc-i2c f0003d40.i2c: clock 375000 Hz (fdr=137) [1.152637] mpc-i2c f0003d40.i2c: timeout 100 us [1.170628] rtc-ds1307 1-0068: rtc core: registered ds1337 as rtc0 [1.181003] BUG: key cf9ea5ac not in .data! [1.185510] [ cut here ] [1.190257] Badness at kernel/lockdep.c:2706 [1.194627] NIP: c004d2b4 LR: c004d29c CTR: c01aeb30 [1.199714] REGS: cf82db70 TRAP: 0700 Not tainted (2.6.34-rc1-dirty) [1.206483] MSR: 00029032 CR: 22084022 XER: 2000 [1.213305] TASK = cf83[1] 'swapper' THREAD: cf82c000 [1.218651] GPR00: cf82dc20 cf83 0001 0001 c0023fb4 0001 [1.227243] GPR08: c03f c03c 0001 42084024 100958e4 0ffef000 0ffe41a4 [1.235834] GPR16: 0ffbf298 0ffe4180 0ff72db4 0ff72cb4 c03d685c c03d6830 [1.244423] GPR24: fff4 0001 c03f 0080 cfa1c2d8 cf9ea5ac cfa1c4d8 [1.253225] NIP [c004d2b4] lockdep_init_map+0xc4/0x4e4 [1.258489] LR [c004d29c] lockdep_init_map+0xac/0x4e4 [1.263657] Call Trace: [1.266165] [cf82dc20] [c004d28c] lockdep_init_map+0x9c/0x4e4 (unreliable) [1.273236] [cf82dc50] [c00de478] sysfs_add_file_mode+0x5c/0xe0 [1.279308] [cf82dc80] [c00e0bbc] sysfs_create_bin_file+0x34/0x50 [1.285575] [cf82dc90] [c01b8764] at24_probe+0x314/0x460 [1.291034] [cf82dcd0] [c0215768] i2c_device_probe+0xac/0xc0 [1.296840] [cf82dcf0] [c01b334c] driver_probe_device+0xa4/0x190 [1.303000] [cf82dd10] [c01b23c0] bus_for_each_drv+0x70/0xac [1.308806] [cf82dd40] [c01b3620] device_attach+0x84/0xa8 [1.314343] [cf82dd60] [c01b1fd8] bus_probe_device+0x3c/0x54 [1.320166] [cf82dd70] [c01b0588] device_add+0x374/0x5f4 [1.325619] [cf82ddc0] [c0216ac4] i2c_new_device+0xf0/0x144 [1.331344] [cf82dde0] [c021b078] of_register_i2c_devices+0x12c/0x158 [1.337966] [cf82de60] [c02c1280] fsl_i2c_probe+0x190/0x324 [1.343687] [cf82de90] [c021abe8] of_platform_device_probe+0x5c/0x84 [1.350208] [cf82deb0] [c01b334c] driver_probe_device+0xa4/0x190 [1.356371] [cf82ded0] [c01b36e8] __driver_attach+0xa4/0xa8 [1.362087] [cf82def0] [c01b259c] bus_for_each_dev+0x60/0x9c [1.367890] [cf82df20] [c01b3164] driver_attach+0x24/0x34 [1.373429] [cf82df30] [c01b2ef4] bus_add_driver+0x1a8/0x264 [1.379235] [cf82df60] [c01b3964] driver_register+0x6c/0x160 [1.385043] [cf82df80] [c021aac0] of_register_driver+0x54/0x70 [1.391040] [cf82df90] [c03ae9fc] fsl_i2c_init+0x24/0x54 [1.396497] [cf82dfa0] [c00038a0] do_one_initcall+0x40/0x1d4 [1.402305] [cf82dfd0] [c039a1e0] kernel_init+0xc4/0x16c [1.407771] [cf82dff0] [c00110d8] kernel_thread+0x4c/0x68 [1.413300] Instruction dump: [1.416341] 3863256c 4bfd758d 801ac11c 2f80 40beffd4 48140b11 2f83 41beffc8 [1.424309] 3d20c03f 8009c2a0 2f80 40beffb8 <0fe0> 80010034 bac10008 38210030 [1.432600] at24 1-0050: 65536 byte 24c512 EEPROM (writable) Stock 2.6.33 runs flawlessly. Maybe I should add here that there is no eeprom connected to the I2C bus (just a placeholder in the dts file, for a chip on a separate board). Any idea what goes wrong here? Thanks, Albrecht. pgpEVjOjQreEN.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] irq: move some interrupt arch_* functions into struct irq_chip.
On Wed, 2010-03-10 at 18:15 +, Eric W. Biederman wrote: > Ian Campbell writes: > > > On Wed, 2010-03-10 at 17:42 +, Eric W. Biederman wrote: > >> > >> > >> Ian Xen in this sense is simply not x86. irq_cfg is not acpi or > >> ioapic or anything but x86 specific. It has everything to do with > >> having a per cpu vector table of 256 entries and architecturally > >> receiving a vector number when an interrupt is fired. > >> > >> It totally makes sense for Xen to do something different because > >> architecturally it has a completely different irq subsystem. > > > > OK, so that sounds like you would like the same patchset but without the > > irq_cfg renaming? or potentially with renaming to x86_blah instead (I'll > > rework to your preference). > > Currently the renaming really makes it unclear what you are doing and for > some reason the description of the renaming rubbed me the wrong way. Sorry, I started off a bit confused and then totally misunderstood what related to what and I think that came through in the description. I'll respin without the first patch. Ian. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] irq: move some interrupt arch_* functions into struct irq_chip.
On 03/10/2010 09:42 AM, Eric W. Biederman wrote: All we need between the Xen and the rest of x86 is a convention so that we never manage the same irqs. At least for domU we are in an either/or situation so I don't see even that being a problem. Dom0 too. This is part of the work implementing what we discussed a while back - Xen now completely owns the local and IO apics, so dom0 only deals with Xen, not the hardware. Xen has a completely different interrupt setup path, but at least it isn't a mishmash of Xen stuff and native APIC stuff. J ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] irq: move some interrupt arch_* functions into struct irq_chip.
On 03/10/2010 04:51 AM, Ian Campbell wrote:
> On Wed, 2010-03-10 at 12:06 +, Yinghai Lu wrote:
>> On Wed, Mar 10, 2010 at 2:55 AM, wrote:
>>> From: Ian Campbell
>>>
>>> Move arch_init_copy_chip_data and arch_free_chip_data into function
>>> pointers in struct irq_chip since they operate on irq_desc->chip_data.
>>>
>>> arch_init_chip_data cannot be moved into struct irq_chip at this time
>>> because irq_desc->chip is not known at the time the irq_desc is
>>> setup. For now rename arch_init_chip_data to arch_init_irq_desc (for
>>> PowerPC, the only other user, whose usage better matches the new name)
>>> and on x86 convert arch_init_chip_data to ioapic_init_chip_data and
>>> call this whenever the IO APIC code allocates a new IRQ.
>>>
>>> I've retained the chip_data behaviour for uv_irq although it isn't
>>> clear to me if these interrupt types support migration or how closely
>>> related to the APIC modes they really are. If it weren't for this the
>>> ioapic_{init,copy,free}_chip_data functions could be static to
>>> io_apic.c.
>>>
>>> I've tested by booting on a 64 bit system, but it's not clear to me
>>> what actions I need to take to actually exercise some of these code
>>> paths.
>>>
>>
>> can you just add another pointer field in irq_desc?
>>
>> some kind of *irq_info etc.
>
> I think I don't understand what you are suggesting.
>
> There is already a pointer for irq_chip specific use i.e.
> irq_desc->chip_data. This patchset is just about ensuring that the field
> really is available to any chip implementation rather than just assuming
> it is always used for the acpi chip types (on x86 at least).
>
> Does adding a second pointer with the same (intended?) semantics as the
> existing one buy us anything?
#ifdef CONFIG_INTR_REMAP
struct irq_2_iommu *irq_2_iommu;
#endif
struct irq_chip *chip;
struct msi_desc *msi_desc;
we already have that for irq_2_iommu and msi_desc
YH
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] irq: move some interrupt arch_* functions into struct irq_chip.
Ian Campbell writes: > On Wed, 2010-03-10 at 10:55 +, i...@hellion.org.uk wrote: >> >> arch_init_chip_data cannot be moved into struct irq_chip at this time >> because irq_desc->chip is not known at the time the irq_desc is >> setup. For now rename arch_init_chip_data to arch_init_irq_desc (for >> PowerPC, the only other user, whose usage better matches the new name) >> and on x86 convert arch_init_chip_data to ioapic_init_chip_data and >> call this whenever the IO APIC code allocates a new IRQ. > > One idea I had to improve this was to add a struct irq_chip * as a > parameter to irq_to_desc_alloc_node. The new parameter potentially could > be NULL for current behaviour. Does that sound like a reasonable > approach? I don't follow why we have the restriction that irq_to_desc_alloc_node must call arch_init_chip_data. Assuming that requirement to call arch_init_chip_data is valid, passing something into init_one_irq_desc seems appropriate. Eric ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] irq: move some interrupt arch_* functions into struct irq_chip.
Yinghai Lu writes:
> On 03/10/2010 04:51 AM, Ian Campbell wrote:
>> On Wed, 2010-03-10 at 12:06 +, Yinghai Lu wrote:
>>> On Wed, Mar 10, 2010 at 2:55 AM, wrote:
From: Ian Campbell
Move arch_init_copy_chip_data and arch_free_chip_data into function
pointers in struct irq_chip since they operate on irq_desc->chip_data.
arch_init_chip_data cannot be moved into struct irq_chip at this time
because irq_desc->chip is not known at the time the irq_desc is
setup. For now rename arch_init_chip_data to arch_init_irq_desc (for
PowerPC, the only other user, whose usage better matches the new name)
and on x86 convert arch_init_chip_data to ioapic_init_chip_data and
call this whenever the IO APIC code allocates a new IRQ.
I've retained the chip_data behaviour for uv_irq although it isn't
clear to me if these interrupt types support migration or how closely
related to the APIC modes they really are. If it weren't for this the
ioapic_{init,copy,free}_chip_data functions could be static to
io_apic.c.
I've tested by booting on a 64 bit system, but it's not clear to me
what actions I need to take to actually exercise some of these code
paths.
>>>
>>> can you just add another pointer field in irq_desc?
>>>
>>> some kind of *irq_info etc.
>>
>> I think I don't understand what you are suggesting.
>>
>> There is already a pointer for irq_chip specific use i.e.
>> irq_desc->chip_data. This patchset is just about ensuring that the field
>> really is available to any chip implementation rather than just assuming
>> it is always used for the acpi chip types (on x86 at least).
>>
>> Does adding a second pointer with the same (intended?) semantics as the
>> existing one buy us anything?
>
>
> #ifdef CONFIG_INTR_REMAP
> struct irq_2_iommu *irq_2_iommu;
> #endif
> struct irq_chip *chip;
> struct msi_desc *msi_desc;
>
> we already have that for irq_2_iommu and msi_desc
Those are at different levels of the hierarchy. Adding another pointer
for Xen is like having a different iommu and so adding another pointer
to handle that kind of iommu.
Eric
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc: Build fix for mpc52xx
mpc52xx_gpt_wdt_setup is defined as 0, which causes the following build
failure with gcc 4.5, since it's built with -Werror.
arch/powerpc/platforms/52xx/mpc52xx_gpt.c:761:3: error: statement with no effect
Defining it as do { } while(0) fixes the problem.
Signed-off-by: Jeff Mahoney
---
arch/powerpc/platforms/52xx/mpc52xx_gpt.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/arch/powerpc/platforms/52xx/mpc52xx_gpt.c
+++ b/arch/powerpc/platforms/52xx/mpc52xx_gpt.c
@@ -711,7 +711,7 @@ static int __devinit mpc52xx_gpt_wdt_ini
return 0;
}
-#define mpc52xx_gpt_wdt_setup(x, y)(0)
+#define mpc52xx_gpt_wdt_setup(x, y)do { } while(0)
#endif /* CONFIG_MPC5200_WDT */
--
Jeff Mahoney
SUSE Labs
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 05/13] powerpc/476: Add isync after loading mmu and debug spr's
On Sun, 2010-03-07 at 15:08 -0800, Hollis Blanchard wrote: > On Fri, Mar 5, 2010 at 12:43 PM, Dave Kleikamp > wrote: > > > > powerpc/476: Add isync after loading mmu and debug spr's > > > > From: Dave Kleikamp > > > > 476 requires an isync after loading MMU and debug related SPR's. Some of > > these are in performance-critical paths and may need to be optimized, but > > initially, we're playing it safe. > > Why is there sometimes #ifdef CONFIG_PPC_47x, sometimes not, and never > the cputable infrastructure which was intended for this sort of thing? The places without an ifdef are either in cpu initialization code, where the cost of an isync is insignificant or, in one case, in 47x-specific code. I was having problems trying to get the cputable infrastructure compiling in inline assembly in the *.c files, but I could have used that in some places. Currently, one can't build with CONFIG_PPC_47x for a non-47x cpu, and we want to re-evaluate whether we can get by without these isyncs. So basically, I plan to clean this up somehow by the time we have a working unified 44x/47x binary kernel. Thanks, Shaggy -- David Kleikamp IBM Linux Technology Center ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 1/6] arch/powerpc/platforms/pseries: Use kasprintf
From: Julia Lawall
kasprintf combines kmalloc and sprintf, and takes care of the size
calculation itself.
The semantic patch that makes this change is as follows:
(http://coccinelle.lip6.fr/)
//
@@
expression a,flag;
expression list args;
statement S;
@@
a =
- \(kmalloc\|kzalloc\)(...,flag)
+ kasprintf(flag,args)
<... when != a
if (a == NULL || ...) S
...>
- sprintf(a,args);
//
Signed-off-by: Julia Lawall
---
arch/powerpc/platforms/pseries/dlpar.c |7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff -u -p a/arch/powerpc/platforms/pseries/dlpar.c
b/arch/powerpc/platforms/pseries/dlpar.c
--- a/arch/powerpc/platforms/pseries/dlpar.c
+++ b/arch/powerpc/platforms/pseries/dlpar.c
@@ -78,13 +78,12 @@ static struct device_node *dlpar_parse_c
* prepend this to the full_name.
*/
name = (char *)ccwa + ccwa->name_offset;
- dn->full_name = kmalloc(strlen(name) + 2, GFP_KERNEL);
+ dn->full_name = kasprintf(GFP_KERNEL, "/%s", name);
if (!dn->full_name) {
kfree(dn);
return NULL;
}
- sprintf(dn->full_name, "/%s", name);
return dn;
}
@@ -409,15 +408,13 @@ static ssize_t dlpar_cpu_probe(const cha
* directory of the device tree. CPUs actually live in the
* cpus directory so we need to fixup the full_name.
*/
- cpu_name = kzalloc(strlen(dn->full_name) + strlen("/cpus") + 1,
- GFP_KERNEL);
+ cpu_name = kasprintf(GFP_KERNEL, "/cpus%s", dn->full_name);
if (!cpu_name) {
dlpar_free_cc_nodes(dn);
rc = -ENOMEM;
goto out;
}
- sprintf(cpu_name, "/cpus%s", dn->full_name);
kfree(dn->full_name);
dn->full_name = cpu_name;
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] irq: move some interrupt arch_* functions into struct irq_chip.
On Wed, 2010-03-10 at 10:55 +, i...@hellion.org.uk wrote: > From: Ian Campbell > > Move arch_init_copy_chip_data and arch_free_chip_data into function > pointers in struct irq_chip since they operate on irq_desc->chip_data. > > arch_init_chip_data cannot be moved into struct irq_chip at this time > because irq_desc->chip is not known at the time the irq_desc is > setup. For now rename arch_init_chip_data to arch_init_irq_desc (for > PowerPC, the only other user, whose usage better matches the new name) > and on x86 convert arch_init_chip_data to ioapic_init_chip_data and > call this whenever the IO APIC code allocates a new IRQ. Ack on the name change, it should be called arch_init_irq_desc(), the existing name clearly comes from the fact that sparse IRQ was implemented first on x86, and on x86 that routine init's the chip data for a new irq_desc. But semantically arch_init_irq_desc() is the right name, I was just too lazy to change it when I enabled sparse IRQ for powerpc. Can't comment on the rest of the patch. cheers signature.asc Description: This is a digitally signed message part ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: 5200B: BUG in 2.6.34-rc1-dirty while loading at24 driver
Hi Albrecht, > not sure if this is the right place to ask: When I boot a custom 5200B (more Check MAINTAINERS for AT24 ;) > or less Lite-based) board with Linus' git tree (2.6.34-rc1-dirty), I always > get the following bug: Will send a patch in some minutes... Regards, Wolfram -- Pengutronix e.K. | Wolfram Sang| Industrial Linux Solutions | http://www.pengutronix.de/ | signature.asc Description: Digital signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Need help with using the BDI2K to debug exception handlers
Hi all, Okay, I'm putting on my asbestos underwear and hoping I don't sound too stupid. Here's my sitch: we're seeing an illegal instruction exception, but the tracks our diagnostic code we put into the kernel program_check_exception() function claims the instruction is perfectly good. So I want to use the BDI to set a BP in the program exception and poke around at a HW level rather than a SW level that has gone through an unknown number of context switches. Now I know that using the BDI in exceptions is hard to do for lots of reasons, first and foremost among them being the fact that the BDI uses SRR0/1 for it's own purposes. I've been down this path before and know there's problems. But what I'm seeing is even stranger than usual. I've replaced the program exception code in arch/powerpc/kernel/head_32.S with the following: . = 0x700 ProgramCheck: mtspr SPRN_SPRG1,r9 mtspr SPRN_SPRG2,r10 mtspr SPRN_SPRG7,r3 mfspr r9,SPRN_SRR0 mfspr r10,SPRN_SRR1 andis. r3,r10,0x0008 /* is it an illegal instruction? */ beq 1f /* no so continue */ 2: xor r3,r3,r3/* dummy instruction */ b 2b /* loop forever */ 1: mfspr r10,SPRN_SPRG2 mfspr r9,SPRN_SPRG1 EXCEPTION_PROLOG; addir3,r1,STACK_FRAME_OVERHEAD; EXC_XFER_STD(0x700, program_check_exception); (Before everyone flames me, yes I know there's a bug, I didn't restore r3 before continuing to the program_check_exception; it's immaterial to the problem at hand because I don't really care if I ever successfully get into program_check_exception.) The purpose of all this is to save SRR0/1 into GPRs so the BDI doesn't whack them, check to see if the exception is being call because of an illegal instruction, continue on if not, and provide a place to hang a breakpoint if it is an illegal instruction. So I load up this code, connect to the BDI, set a HW BP on the branch instruction following the line labeled '2', tell it to go and sit back to wait. Eventually our problem occurs and the BDI says "TARGET: stopped" or some such, indicating it's hit the breakpoint. This is where things get strange and I need help. At this point the BDI output from the telnet session says the debug entry cause is and the current PC is 0x6fc, one instruction before the program exception. When I dump the registers r9 and r10 contain nothing the even remotely resemble SRR0/1. The link register contains a valid _physical_ address (though I would expect it to contain a virtual address from the last 'bl' instruction) but when I dump the memory pointed to by LR it contains all zeros, not PPC machine code. It looks like my code isn't even running even though it seems I've hit the breakpoint. It's almost as if the BDI recognizes I'm entering an exception that I've set a BP in and halts just before executing the exception code. I'm not sure I believe it, but that's how it appears. Has anyone seen this or have any suggestion on how I can get the BDI to quit 'helping' me and just stop where I tell it to in an exception handler? Thanks Bruce___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
PowerPC 85xx board are caused die by Commit: 864b9e6fd76489aab422bac62162f57c52e06ed8(powerpc: Use lwarx/ldarx hint in bit locks)
Hi Guys: I have done several experiments on fsl_8548cds and fsl_p2020rdb, pinpointed the commit: 864b9e6fd76489aab422bac62162f57c52e06ed8(powerpc: Use lwarx/ldarx hint in bit locks) cause the bootup stalledd. " Filename 'fsl_8548cds/uImage'. Load address: 0x100 Loading: # ### done Bytes transferred = 1526546 (174b12 hex) Speed: 100, full duplex Using eTSEC0 device Filename 'sliu/fsl_8548cds/mpc8548cds.dtb'. Load address: 0xc0 Loading: # done Bytes transferred = 9993 (2709 hex) ## Booting image at 0100 ... Image Name: Linux-2.6.34-rc1-5-g522dba7 Image Type: PowerPC Linux Kernel Image (gzip compressed) Data Size:1526482 Bytes = 1.5 MB Load Address: Entry Point: Verifying Checksum ... OK Uncompressing Kernel Image ... OK Booting using the fdt at 0xc0 Loading Device Tree to 007fb000, end 007fd708 ... OK " I guess all 85xx or booke board has this issue. Thanks Andrew ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: PowerPC 85xx board are caused die by Commit: 864b9e6fd76489aab422bac62162f57c52e06ed8(powerpc: Use lwarx/ldarx hint in bit locks)
On Mar 10, 2010, at 9:20 PM, Andrew Liu wrote: > Hi Guys: > I have done several experiments on fsl_8548cds and fsl_p2020rdb, pinpointed > the commit: 864b9e6fd76489aab422bac62162f57c52e06ed8(powerpc: Use lwarx/ldarx > hint in bit locks) cause the bootup stalledd. > > " > Filename 'fsl_8548cds/uImage'. > Load address: 0x100 > Loading: # > ### > done > Bytes transferred = 1526546 (174b12 hex) > Speed: 100, full duplex > Using eTSEC0 device > Filename 'sliu/fsl_8548cds/mpc8548cds.dtb'. > Load address: 0xc0 > Loading: # > done > Bytes transferred = 9993 (2709 hex) > ## Booting image at 0100 ... >Image Name: Linux-2.6.34-rc1-5-g522dba7 >Image Type: PowerPC Linux Kernel Image (gzip compressed) >Data Size:1526482 Bytes = 1.5 MB >Load Address: >Entry Point: >Verifying Checksum ... OK >Uncompressing Kernel Image ... OK >Booting using the fdt at 0xc0 >Loading Device Tree to 007fb000, end 007fd708 ... OK > " > > I guess all 85xx or booke board has this issue. that's very odd since __PPC_EH should be ignored on PPC32 and thus 85xx. - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc/85xx: Make sure lwarx hint isn't set on ppc32
e500v1/v2 based chips will treat any reserved field being set in an opcode as illegal. Thus always setting the hint in the opcode is a bad idea. Anton should be kept away from the powerpc opcode map. Signed-off-by: Kumar Gala --- arch/powerpc/include/asm/ppc-opcode.h |6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-) diff --git a/arch/powerpc/include/asm/ppc-opcode.h b/arch/powerpc/include/asm/ppc-opcode.h index aea7147..d553bbe 100644 --- a/arch/powerpc/include/asm/ppc-opcode.h +++ b/arch/powerpc/include/asm/ppc-opcode.h @@ -25,7 +25,7 @@ #define PPC_INST_LDARX 0x7ca8 #define PPC_INST_LSWI 0x7c0004aa #define PPC_INST_LSWX 0x7c00042a -#define PPC_INST_LWARX 0x7c29 +#define PPC_INST_LWARX 0x7c28 #define PPC_INST_LWSYNC0x7c2004ac #define PPC_INST_LXVD2X0x7c000698 #define PPC_INST_MCRXR 0x7c000400 @@ -62,8 +62,8 @@ #define __PPC_T_TLB(t) (((t) & 0x3) << 21) #define __PPC_WC(w)(((w) & 0x3) << 21) /* - * Only use the larx hint bit on 64bit CPUs. Once we verify it doesn't have - * any side effects on all 32bit processors, we can do this all the time. + * Only use the larx hint bit on 64bit CPUs. e500v1/v2 based CPUs will treat a + * larx with EH set as an illegal instruction. */ #ifdef CONFIG_PPC64 #define __PPC_EH(eh) (((eh) & 0x1) << 0) -- 1.6.0.6 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: PowerPC 85xx board are caused die by Commit: 864b9e6fd76489aab422bac62162f57c52e06ed8(powerpc: Use lwarx/ldarx hint in bit locks)
On Mar 10, 2010, at 11:20 PM, Kumar Gala wrote: > > On Mar 10, 2010, at 9:20 PM, Andrew Liu wrote: > >> Hi Guys: >> I have done several experiments on fsl_8548cds and fsl_p2020rdb, pinpointed >> the commit: 864b9e6fd76489aab422bac62162f57c52e06ed8(powerpc: Use >> lwarx/ldarx hint in bit locks) cause the bootup stalledd. >> >> " >> Filename 'fsl_8548cds/uImage'. >> Load address: 0x100 >> Loading: # >> ### >> done >> Bytes transferred = 1526546 (174b12 hex) >> Speed: 100, full duplex >> Using eTSEC0 device >> Filename 'sliu/fsl_8548cds/mpc8548cds.dtb'. >> Load address: 0xc0 >> Loading: # >> done >> Bytes transferred = 9993 (2709 hex) >> ## Booting image at 0100 ... >> Image Name: Linux-2.6.34-rc1-5-g522dba7 >> Image Type: PowerPC Linux Kernel Image (gzip compressed) >> Data Size:1526482 Bytes = 1.5 MB >> Load Address: >> Entry Point: >> Verifying Checksum ... OK >> Uncompressing Kernel Image ... OK >> Booting using the fdt at 0xc0 >> Loading Device Tree to 007fb000, end 007fd708 ... OK >> " >> >> I guess all 85xx or booke board has this issue. > > that's very odd since __PPC_EH should be ignored on PPC32 and thus 85xx. Found the issue and posted a fix. - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Freescale MPC5554 device tree (was: cross-compiling Linux for PowerPC e200 core?)
Grant Likely wrote:
> 2010/3/9 Németh Márton :
>> Hi,
>> Grant Likely wrote:
>>> 2010/3/8 Németh Márton :
[snip]
As far as I could find out I'll need to create a device tree as documented
in
the linux/Documentation/powerpc/booting-without-of.txt file.
>>> Yes, you'll need to create a device tree file for the board. Again,
>>> start from an existing 5200 .dts file. You won't need very much in it
>>> to get started. I'd be happy to help you get the structure right.
>> I tried to create a first draft of the deveice tree for MPC5554. It is
>> compilable with dtc. I based this .dts file on Figure 1-1 on page 1-3 and
>> Table 1-2 on page 1-21 of
>> http://www.freescale.com/files/32bit/doc/ref_manual/MPC5553_MPC5554_RM.pdf .
>>
>> I'm not sure about the following points:
>> 1. Where should be the on-chip FLASH described? This memory is read-only from
>> view of software and can be used to store read-only data or execute code
>> directly
>> from there.
>
> Hang it off the xbar node. Name it flash@, and use
> 'compatible = "fsl,mpc5554-flash";'
>
>> 2. Should the co-processor (eTPU in this case) also listed in section "cpus"
>> or not? This co-processor is not able to run code like the e200z6.
>
> No, this is a device. Hang it off the peripheral bridge a node.
>
>> 3. There are three on-chip buses on MPC5554:
>> - Crossbar Switch (XBAR)
>> - Peripheral Bridge A (PBRIDGE_A)
>> - Peripheral Bridge B (PBRIDGE_B)
>> I used PBRIDGE_A and PRIDGE_B to create two /soc entries. Is this
>> possible?
>
> the soc5200 naming was poorly chosen when the 5200 device tree was
> written. Use something like this:
>
> xbar@ {
> compatible = "fsl,mpc5554-xbar";
> #address-cells = <1>;
> #size-cells = <1>;
> ranges = <[put the translation ranges in here]>;
> reg = ;
>
> bridge@ {
> compatible = "fsl,mpc5554-pbridge-a";
> #address-cells = <1>;
> #size-cells = <1>;
> ranges = <[put the translation ranges in here]>;
> reg = ;
> [... child device nodes ...]
> };
> bridge@ {
> compatible = "fsl,mpc5554-pbridge-b";
> #address-cells = <1>;
> #size-cells = <1>;
> ranges = <[put the translation ranges in here]>;
> reg = ;
> [... child device nodes ...]
> };
> };
>
> The idea is to use generic names for the node names, and identify
> exactly what the device is by using the "compatible" property. Also,
> the aim is to build up a tree describing the interconnection of device
> from the perspective of the OS on the CPU. ie. the full physical
> address space is represented by the root node of the tree, and
> everything else hangs off that.
>
>> 4. There are modules which have multiple instances at different base
>> addresses. These
>> are DSPI, SCI and FlexCAN. I used the same name for them but with
>> different addresses.
>> Is this correct?
>
> yes.
[snip]
Here is the next draft version of the Freescale MPC5554 device tree.
I'm not quite sure whether the mem...@4000 should go under xbar or stay
directly under the root node.
The second problem I faced with was that XBAR covers the whole address range.
However, if I specify "ranges = <0 0x 0x1>;" then I get an
error message because of the too big length value:
| DTC: dts->dts on file "/usr/src/linux/arch/powerpc/boot/dts/mpc5554.dts"
| /usr/src/linux/arch/powerpc/boot/dts/mpc5554.dts:51 literal out of range
| FATAL ERROR: Syntax error parsing input tree
I tried to solve this problem by assuming that leaving out the "ranges = ..."
means the whole range. Is this correct?
Regards,
Márton Németh
---
From: Márton Németh
Add device tree for Freescale MPC5554.
Signed-off-by: Márton Németh
---
diff -uprN linux-2.6.33.orig/arch/powerpc/boot/dts/mpc5554.dts
linux/arch/powerpc/boot/dts/mpc5554.dts
--- linux-2.6.33.orig/arch/powerpc/boot/dts/mpc5554.dts 1970-01-01
01:00:00.0 +0100
+++ linux/arch/powerpc/boot/dts/mpc5554.dts 2010-03-11 07:01:29.0
+0100
@@ -0,0 +1,188 @@
+/*
+ * Freescale MPC5554 Device Tree Source
+ *
+ * Based on MPC5553/5554 Microcontroller Reference Manual, Rev. 4.0, 04/2007
+ * http://www.freescale.com/files/32bit/doc/ref_manual/MPC5553_MPC5554_RM.pdf
+ *
+ * Copyright 2010 Márton Németh
+ * Márton Németh
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ */
+
+/dts-v1/;
+
+/ {
+ model = "MPC5554";
+ compatible = "fsl,MPC5554EVB"; // Freescale MPC5554 Evaluation
Board
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ cpus {
+ #address-cells = <1>;
+
Re: Freescale MPC5554 device tree (was: cross-compiling Linux for PowerPC e200 core?)
On Thu, Mar 11, 2010 at 07:11:56AM +0100, Németh Márton wrote:
[snip]
> +/dts-v1/;
> +
> +/ {
> + model = "MPC5554";
> + compatible = "fsl,MPC5554EVB"; // Freescale MPC5554 Evaluation
> Board
> + #address-cells = <1>;
> + #size-cells = <1>;
> +
> + cpus {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + PowerPC,5...@0 {
Modern best practice is to have the cpu nodes named just "c...@xxx",
and put the PowerPC, into the compatible property.
> + device_type = "cpu";
> + reg = <0>;
> + d-cache-line-size = <32>;
> + i-cache-line-size = <32>;
> + d-cache-size = <0x8000>;// L1, 32KiB
> + i-cache-size = <0x8000>;// L1, 32KiB
> + timebase-frequency = <0>; // from bootloader
> + bus-frequency = <0>;// from bootloader
> + clock-frequency = <0>; // from bootloader
> + };
> + };
> +
> + mem...@4000 {
> + device_type = "memory";
> + reg = <0x4000 0x1>; // 32KiB internal SRAM
> + };
> +
> + x...@1ff04000 { // System Bus Crossbar Switch (XBAR)
> + compatible = "fsl,mpc5554-xbar";
> + #address-cells = <1>;
> + #size-cells = <1>;
> + // The full memory range is covered by XBAR
> +// ranges = <0 0x 0x1>;
If you want all addresses to be translated by the bus you need an
empty ranges property, not *no* ranges property. No ranges property
indicates that addresses cannot be directly translated across the
bridge, which is not, I think, what you intend.
> + reg = <0xfff04000 0x4000>;
The unit address '@1ff04000' does not match your reg property 0xfff04000.
> +
> + fl...@ {// read-only FLASH
Unit addresses are not 0 padded, so this should be just 'fl...@0'.
> + compatible = "fsl,mpc5554-flash";
> + reg = <0x 0x20>;// 2MiB internal FLASH
> + };
> +
> + bri...@c000 {
> + compatible = "fsl,mpc5554-pbridge-a";
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges = <0 0xc000 0x2000>;
> + reg = <0xc3f0 0x4000>;
The unit address is based on 'reg' (if present) not ranges, so it
should be bri...@c3f0. Likewise for the other bridge below.
--
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@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Problem with PCI bus rescan on 460EX
Hi Alex, Resending, previous attempt was erroneously send as HTML. Thanks a lot for replying. Alex Chiang wrote: * Felix Radensky : The problem arises when device is plugged in after boot. After doing echo 1 > /sys/bus/pci/rescan the device is identified, but bridge memory window is not allocated, and reads from device memory regions return 0x. Below is relevant output: Do you need firmware support on your platform for hotplug? I don't think so, but I've added powerpc guys to CC to make sure. Can you please send full dmesg during successful boot, full dmesg log during unsuccessful rescan, and contents of /proc/iomem and /proc/ioports during success and failure cases? Be sure you have PCI_CONFIG_DEBUG turned on. Attached. I really appreciate your help. Thanks a lot. Felix. Linux version 2.6.33 (fe...@felix-laptop.lan) (gcc version 4.2.2) #5 Thu Mar 11 09:35:52 IST 2010 Found legacy serial port 0 for /plb/opb/ser...@ef600300 mem=4ef600300, taddr=4ef600300, irq=0, clk=7407407, speed=0 Found legacy serial port 1 for /plb/opb/ser...@ef600400 mem=4ef600400, taddr=4ef600400, irq=0, clk=7407407, speed=0 Found legacy serial port 2 for /plb/opb/ser...@ef600500 mem=4ef600500, taddr=4ef600500, irq=0, clk=7407407, speed=0 Found legacy serial port 3 for /plb/opb/ser...@ef600600 mem=4ef600600, taddr=4ef600600, irq=0, clk=7407407, speed=0 Top of RAM: 0x3000, Total RAM: 0x3000 Memory hole size: 0MB Zone PFN ranges: DMA 0x -> 0x0003 Normal 0x0003 -> 0x0003 Movable zone start PFN for each node early_node_map[1] active PFN ranges 0: 0x -> 0x0003 On node 0 totalpages: 196608 free_area_init_node: node 0, pgdat c035e76c, node_mem_map c0388000 DMA zone: 1536 pages used for memmap DMA zone: 0 pages reserved DMA zone: 195072 pages, LIFO batch:31 MMU: Allocated 1088 bytes of context maps for 255 contexts Built 1 zonelists in Zone order, mobility grouping on. Total pages: 195072 Kernel command line: root=/dev/nfs rw nfsroot=10.0.0.10:/opt/eldk/ppc_4xxFP ip=10.0.0.30:10.0.0.10:10.0.0.138:255.0.0.0:smbe460:eth0:off panic=1 console=ttyS0,115200 PID hash table entries: 4096 (order: 2, 16384 bytes) Dentry cache hash table entries: 131072 (order: 7, 524288 bytes) Inode-cache hash table entries: 65536 (order: 6, 262144 bytes) Memory: 775552k/786432k available (3364k kernel code, 10604k reserved, 116k data, 128k bss, 144k init) Kernel virtual memory layout: * 0xfffdf000..0xf000 : fixmap * 0xfde0..0xfe00 : consistent mem * 0xfde0..0xfde0 : early ioremap * 0xf100..0xfde0 : vmalloc & ioremap SLUB: Genslabs=11, HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1 Hierarchical RCU implementation. NR_IRQS:512 nr_irqs:512 UIC0 (32 IRQ sources) at DCR 0xc0 UIC1 (32 IRQ sources) at DCR 0xd0 alloc irq_desc for 30 on node 0 alloc kstat_irqs on node 0 irq: irq 30 on host /interrupt-controller0 mapped to virtual irq 30 UIC2 (32 IRQ sources) at DCR 0xe0 alloc irq_desc for 16 on node 0 alloc kstat_irqs on node 0 irq: irq 10 on host /interrupt-controller0 mapped to virtual irq 16 UIC3 (32 IRQ sources) at DCR 0xf0 alloc irq_desc for 17 on node 0 alloc kstat_irqs on node 0 irq: irq 16 on host /interrupt-controller0 mapped to virtual irq 17 time_init: decrementer frequency = 1000.12 MHz time_init: processor frequency = 1000.12 MHz clocksource: timebase mult[40] shift[22] registered clockevent: decrementer mult[8019] shift[31] cpu[0] Mount-cache hash table entries: 512 NET: Registered protocol family 16 alloc irq_desc for 18 on node 0 alloc kstat_irqs on node 0 irq: irq 11 on host /interrupt-controller1 mapped to virtual irq 18 256k L2-cache enabled PCI host bridge /plb/p...@c0ec0 (primary) ranges: MEM 0x000d8000..0x000d -> 0x8000 MEM 0x000c0ee0..0x000c0eef -> 0x IO 0x000c0800..0x000c0800 -> 0x Removing ISA hole at 0x000c0ee0 4xx PCI DMA offset set to 0x /plb/p...@c0ec0: Legacy ISA memory support enabled PCI: Probing PCI hardware pci_bus :00: scanning bus pci :00:02.0: found [3388:0020] class 000604 header type 01 pci :00:02.0: calling pcibios_fixup_resources+0x0/0xf4 pci :00:02.0: calling fixup_ppc4xx_pci_bridge+0x0/0x154 pci :00:02.0: calling quirk_resource_alignment+0x0/0x200 pci :00:02.0: supports D1 D2 pci :00:02.0: PME# supported from D0 D1 D2 D3hot pci :00:02.0: PME# disabled pci_bus :00: fixups for bus pci :00:02.0: scanning behind bridge, config 00, pass 0 pci :00:02.0: bus configuration invalid, reconfiguring pci :00:02.0: scanning behind bridge, config 00, pass 1 pci_bus :01: scanning bus pci_bus :01: fixups for bus pci :00:02.0: PCI bridge to [bus 01-ff] pci :00:02.0: bridge window [io 0x-0x0fff] pci :00:02.0: bridge window [mem 0x-0x000f] pci :0
