* [PATCH] powerpc: Add xmon function to dump 44x TLB
From: Benjamin Herrenschmidt @ 2007-11-16 7:23 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev
This adds a function to xmon to dump the content of the 44x processor
TLB with a little bit of decoding (but not much).
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
Did that to track down some machine checks I was having while working
on PCI support due to 32/64 bits resource screwage.
Useful to see where a given MMIO virtual address really maps to.
arch/powerpc/xmon/xmon.c | 38 ++++++++++++++++++++++++++++++++++++++
1 file changed, 38 insertions(+)
Index: linux-work/arch/powerpc/xmon/xmon.c
===================================================================
--- linux-work.orig/arch/powerpc/xmon/xmon.c 2007-11-16 16:33:03.000000000 +1100
+++ linux-work/arch/powerpc/xmon/xmon.c 2007-11-16 16:50:45.000000000 +1100
@@ -153,6 +153,10 @@ static const char *getvecname(unsigned l
static int do_spu_cmd(void);
+#ifdef CONFIG_44x
+static void dump_tlb_44x(void);
+#endif
+
int xmon_no_auto_backtrace;
extern void xmon_enter(void);
@@ -231,6 +235,9 @@ Commands:\n\
#ifdef CONFIG_PPC_STD_MMU_32
" u dump segment registers\n"
#endif
+#ifdef CONFIG_44x
+" u dump TLB\n"
+#endif
" ? help\n"
" zr reboot\n\
zh halt\n"
@@ -856,6 +863,11 @@ cmds(struct pt_regs *excp)
dump_segments();
break;
#endif
+#ifdef CONFIG_4xx
+ case 'u':
+ dump_tlb_44x();
+ break;
+#endif
default:
printf("Unrecognized command: ");
do {
@@ -2581,6 +2593,32 @@ void dump_segments(void)
}
#endif
+#ifdef CONFIG_44x
+static void dump_tlb_44x(void)
+{
+ int i;
+
+ for (i = 0; i < PPC44x_TLB_SIZE; i++) {
+ unsigned long w0,w1,w2;
+ asm volatile("tlbre %0,%1,0" : "=r" (w0) : "r" (i));
+ asm volatile("tlbre %0,%1,1" : "=r" (w1) : "r" (i));
+ asm volatile("tlbre %0,%1,2" : "=r" (w2) : "r" (i));
+ printf("[%02x] %08x %08x %08x ", i, w0, w1, w2);
+ if (w0 & PPC44x_TLB_VALID) {
+ printf("V %08x -> %01x%08x %c%c%c%c%c",
+ w0 & PPC44x_TLB_EPN_MASK,
+ w1 & PPC44x_TLB_ERPN_MASK,
+ w1 & PPC44x_TLB_RPN_MASK,
+ (w2 & PPC44x_TLB_W) ? 'W' : 'w',
+ (w2 & PPC44x_TLB_I) ? 'I' : 'i',
+ (w2 & PPC44x_TLB_M) ? 'M' : 'm',
+ (w2 & PPC44x_TLB_G) ? 'G' : 'g',
+ (w2 & PPC44x_TLB_E) ? 'E' : 'e');
+ }
+ printf("\n");
+ }
+}
+#endif /* CONFIG_44x */
void xmon_init(int enable)
{
#ifdef CONFIG_PPC_ISERIES
^ permalink raw reply
* [PATCH] powerpc: Fix 44x Machine Check handling
From: Benjamin Herrenschmidt @ 2007-11-16 7:21 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev
This removes the old CONFIG_440A which was a pain for multiplatform
kernel and wasn't set properly by default and replaces it with a
CPU feature. This makes Machine Check reporting work correctly on
my Ebony (440GP) board.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
Note: I'm only setting it for 440GX and EPx as the old code did,
I haven't checked whether other new 440 chips such as SPe also
need that bit set.
arch/powerpc/kernel/cputable.c | 10 +++++-----
arch/powerpc/kernel/head_44x.S | 11 ++++++-----
arch/powerpc/kernel/traps.c | 19 ++++++++-----------
arch/powerpc/platforms/44x/Kconfig | 5 -----
include/asm-powerpc/cputable.h | 3 ++-
include/asm-powerpc/reg_booke.h | 2 +-
6 files changed, 22 insertions(+), 28 deletions(-)
Index: linux-work/arch/powerpc/kernel/cputable.c
===================================================================
--- linux-work.orig/arch/powerpc/kernel/cputable.c 2007-11-16 16:15:29.000000000 +1100
+++ linux-work/arch/powerpc/kernel/cputable.c 2007-11-16 16:17:42.000000000 +1100
@@ -1158,7 +1158,7 @@ static struct cpu_spec __initdata cpu_sp
.pvr_mask = 0xf0000ffb,
.pvr_value = 0x200008D8,
.cpu_name = "440EPX",
- .cpu_features = CPU_FTRS_44X,
+ .cpu_features = CPU_FTRS_44X | CPU_FTR_440A,
.cpu_user_features = COMMON_USER_BOOKE | PPC_FEATURE_HAS_FPU,
.icache_bsize = 32,
.dcache_bsize = 32,
@@ -1189,7 +1189,7 @@ static struct cpu_spec __initdata cpu_sp
.pvr_mask = 0xf0000fff,
.pvr_value = 0x50000850,
.cpu_name = "440GX Rev. A",
- .cpu_features = CPU_FTRS_44X,
+ .cpu_features = CPU_FTRS_44X | CPU_FTR_440A,
.cpu_user_features = COMMON_USER_BOOKE,
.icache_bsize = 32,
.dcache_bsize = 32,
@@ -1199,7 +1199,7 @@ static struct cpu_spec __initdata cpu_sp
.pvr_mask = 0xf0000fff,
.pvr_value = 0x50000851,
.cpu_name = "440GX Rev. B",
- .cpu_features = CPU_FTRS_44X,
+ .cpu_features = CPU_FTRS_44X | CPU_FTR_440A,
.cpu_user_features = COMMON_USER_BOOKE,
.icache_bsize = 32,
.dcache_bsize = 32,
@@ -1209,7 +1209,7 @@ static struct cpu_spec __initdata cpu_sp
.pvr_mask = 0xf0000fff,
.pvr_value = 0x50000892,
.cpu_name = "440GX Rev. C",
- .cpu_features = CPU_FTRS_44X,
+ .cpu_features = CPU_FTRS_44X | CPU_FTR_440A,
.cpu_user_features = COMMON_USER_BOOKE,
.icache_bsize = 32,
.dcache_bsize = 32,
@@ -1219,7 +1219,7 @@ static struct cpu_spec __initdata cpu_sp
.pvr_mask = 0xf0000fff,
.pvr_value = 0x50000894,
.cpu_name = "440GX Rev. F",
- .cpu_features = CPU_FTRS_44X,
+ .cpu_features = CPU_FTRS_44X | CPU_FTR_440A,
.cpu_user_features = COMMON_USER_BOOKE,
.icache_bsize = 32,
.dcache_bsize = 32,
Index: linux-work/arch/powerpc/kernel/head_44x.S
===================================================================
--- linux-work.orig/arch/powerpc/kernel/head_44x.S 2007-11-16 16:21:49.000000000 +1100
+++ linux-work/arch/powerpc/kernel/head_44x.S 2007-11-16 16:27:12.000000000 +1100
@@ -197,7 +197,7 @@ skpinv: addi r4,r4,1 /* Increment */
/* Establish the interrupt vector offsets */
SET_IVOR(0, CriticalInput);
- SET_IVOR(1, MachineCheck);
+ SET_IVOR(1, MachineCheck); /* patched later on 440A */
SET_IVOR(2, DataStorage);
SET_IVOR(3, InstructionStorage);
SET_IVOR(4, ExternalInput);
@@ -237,6 +237,10 @@ skpinv: addi r4,r4,1 /* Increment */
bl early_init
+BEGIN_FTR_SECTION
+ SET_IVOR(1, MachineCheckA);
+END_FTR_SECTION_IFSET(CPU_FTR_440A)
+
/*
* Decide what sort of machine this is and initialize the MMU.
*/
@@ -289,11 +293,8 @@ interrupt_base:
CRITICAL_EXCEPTION(0x0100, CriticalInput, unknown_exception)
/* Machine Check Interrupt */
-#ifdef CONFIG_440A
- MCHECK_EXCEPTION(0x0200, MachineCheck, machine_check_exception)
-#else
CRITICAL_EXCEPTION(0x0200, MachineCheck, machine_check_exception)
-#endif
+ MCHECK_EXCEPTION(0x0200, MachineCheckA, machine_check_exception)
/* Data Storage Interrupt */
START_EXCEPTION(DataStorage)
Index: linux-work/arch/powerpc/kernel/traps.c
===================================================================
--- linux-work.orig/arch/powerpc/kernel/traps.c 2007-11-16 16:19:52.000000000 +1100
+++ linux-work/arch/powerpc/kernel/traps.c 2007-11-16 16:28:58.000000000 +1100
@@ -338,20 +338,16 @@ static int generic_machine_check_excepti
{
unsigned long reason = get_mc_reason(regs);
-#if defined(CONFIG_4xx) && !defined(CONFIG_440A)
- if (reason & ESR_IMCP) {
- printk("Instruction");
- mtspr(SPRN_ESR, reason & ~ESR_IMCP);
- } else
- printk("Data");
- printk(" machine check in kernel mode.\n");
-#elif defined(CONFIG_440A)
+#if defined(CONFIG_4xx)
printk("Machine check in kernel mode.\n");
if (reason & ESR_IMCP){
- printk("Instruction Synchronous Machine Check exception\n");
+ if (cpu_has_feature(CPU_FTR_440A))
+ printk("Instruction Synchronous Machine Check exception\n");
+ else
+ printk("Instruction Machine Check exception\n");
mtspr(SPRN_ESR, reason & ~ESR_IMCP);
}
- else {
+ else if (cpu_has_feature(CPU_FTR_440A)) {
u32 mcsr = mfspr(SPRN_MCSR);
if (mcsr & MCSR_IB)
printk("Instruction Read PLB Error\n");
@@ -374,7 +370,8 @@ static int generic_machine_check_excepti
/* Clear MCSR */
mtspr(SPRN_MCSR, mcsr);
- }
+ } else
+ printk("Data Machine Check exception\n");
#elif defined (CONFIG_E500)
printk("Machine check in kernel mode.\n");
printk("Caused by (from MCSR=%lx): ", reason);
Index: linux-work/arch/powerpc/platforms/44x/Kconfig
===================================================================
--- linux-work.orig/arch/powerpc/platforms/44x/Kconfig 2007-11-16 16:13:49.000000000 +1100
+++ linux-work/arch/powerpc/platforms/44x/Kconfig 2007-11-16 16:29:28.000000000 +1100
@@ -62,11 +62,6 @@ config 440GX
config 440SP
bool
-config 440A
- bool
- depends on 440GX || 440EPX
- default y
-
# 44x errata/workaround config symbols, selected by the CPU models above
config IBM440EP_ERR42
bool
Index: linux-work/include/asm-powerpc/cputable.h
===================================================================
--- linux-work.orig/include/asm-powerpc/cputable.h 2007-11-16 16:14:29.000000000 +1100
+++ linux-work/include/asm-powerpc/cputable.h 2007-11-16 16:19:35.000000000 +1100
@@ -138,6 +138,7 @@ extern void do_feature_fixups(unsigned l
#define CPU_FTR_FPU_UNAVAILABLE ASM_CONST(0x0000000000800000)
#define CPU_FTR_UNIFIED_ID_CACHE ASM_CONST(0x0000000001000000)
#define CPU_FTR_SPE ASM_CONST(0x0000000002000000)
+#define CPU_FTR_440A ASM_CONST(0x0000000004000000)
/*
* Add the 64-bit processor unique features in the top half of the word;
@@ -400,7 +401,7 @@ enum {
CPU_FTRS_40X |
#endif
#ifdef CONFIG_44x
- CPU_FTRS_44X |
+ CPU_FTRS_44X | CPU_FTR_440A |
#endif
#ifdef CONFIG_E200
CPU_FTRS_E200 |
Index: linux-work/include/asm-powerpc/reg_booke.h
===================================================================
--- linux-work.orig/include/asm-powerpc/reg_booke.h 2007-11-16 16:28:40.000000000 +1100
+++ linux-work/include/asm-powerpc/reg_booke.h 2007-11-16 16:28:43.000000000 +1100
@@ -207,7 +207,7 @@
#define CCR1_TCS 0x00000080 /* Timer Clock Select */
/* Bit definitions for the MCSR. */
-#ifdef CONFIG_440A
+#ifdef CONFIG_4xx
#define MCSR_MCS 0x80000000 /* Machine Check Summary */
#define MCSR_IB 0x40000000 /* Instruction PLB Error */
#define MCSR_DRB 0x20000000 /* Data Read PLB Error */
^ permalink raw reply
* Re: [PATCH] [POWERPC] Fix link errors for allyesconfig
From: David Miller @ 2007-11-16 6:23 UTC (permalink / raw)
To: sfr; +Cc: linuxppc-dev, paulus
In-Reply-To: <20071104132839.ea04cf6b.sfr@canb.auug.org.au>
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Sun, 4 Nov 2007 13:28:39 +1100
> Dave, would something like this help as an alternative to the .fixup
> change you committed recently?
I tried it, doesn't help:
kernel/built-in.o: In function `context_switch':
/home/davem/src/GIT/sparc-2.6/kernel/sched.c:1950: relocation truncated to fit: R_SPARC_WDISP22 against symbol `ret_from_syscall' defined in .text section in arch/sparc64/kernel/head.o
drivers/built-in.o:(.fixup+0x0): relocation truncated to fit: R_SPARC_WDISP22 against `.text'
drivers/built-in.o:(.fixup+0x8): relocation truncated to fit: R_SPARC_WDISP22 against `.text'
drivers/built-in.o:(.fixup+0x10): relocation truncated to fit: R_SPARC_WDISP22 against `.text'
drivers/built-in.o:(.fixup+0x18): relocation truncated to fit: R_SPARC_WDISP22 against `.text'
drivers/built-in.o:(.fixup+0x20): relocation truncated to fit: R_SPARC_WDISP22 against `.text'
drivers/built-in.o:(.fixup+0x2c): relocation truncated to fit: R_SPARC_WDISP22 against `.text'
drivers/built-in.o:(.fixup+0x38): relocation truncated to fit: R_SPARC_WDISP22 against `.text'
drivers/built-in.o:(.fixup+0x44): relocation truncated to fit: R_SPARC_WDISP22 against `.text'
drivers/built-in.o:(.fixup+0x50): relocation truncated to fit: R_SPARC_WDISP22 against `.text'
drivers/built-in.o:(.fixup+0x5c): additional relocation overflows omitted from the output
make: *** [.tmp_vmlinux1] Error 1
drivers/built-in.o itself has a 16MB+ .text section which is
beyond the 22-bit signed branch displacement we have available.
There has to be a nicer way to do this. In fact I think I
just figured out one such technique.
The whole reason we need these .fixup sections is to encode
a move of -EFAULT into some register, and a control transfer.
Every kernel text address, even for modules, is in the low 32-bits on
sparc64. So we can encode this more simply, perhaps even with one
32-bit word for each entry.
I can probably encode it all in the __ex_table entries in fact,
and I'll give that a shot.
^ permalink raw reply
* Re: Please pull from for-2.6.24
From: Zang Roy-r61911 @ 2007-11-16 5:54 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev list, Paul Mackerras
In-Reply-To: <20070914122510.6dffb747@weaponx.rchland.ibm.com>
On Sat, 2007-09-15 at 01:25, Josh Boyer wrote:
> On Fri, 14 Sep 2007 09:02:04 -0500
> Kumar Gala <galak@kernel.crashing.org> wrote:
>
> >
> > On Sep 13, 2007, at 3:55 PM, Kumar Gala wrote:
> >
> > > Please pull from 'for-2.6.24' branch of
> > >
> > > master.kernel.org:/pub/scm/linux/kernel/git/galak/powerpc.git
> > > for-2.6.24
> > >
> > > to receive the following updates:
> >
> > I've updated the branch with the following changes:
> >
> > > Anton Vorontsov (3):
> > > [POWERPC] MPC832x_RDB: Update dts to use SPI1 in QE,
> register
> > > mmc_spi stub
> >
> > Updated commit message. (let me know if you want me to drop this
> for
> > now and wait til mmc_spi gets merged)
> >
> > > Roy Zang (1):
> > > [POWERPC] Update mpc7448hpc2 device tree to be compatible
> for
> > > tsi109 chip
> >
> > Dropped for now. I doubt we want this based on Segher's comments.
> > (pretty sure its a ts108 on the hpc2 board).
>
> It is a tsi108 on hpc2. Holly has tsi109. From a Linux perspective,
> there is no difference. And the comment Segher made on the list was
> "Looks good, thanks!" So what other comment are you talking about?
Hi, guys
In fact, I was confused by this chain.
Original hpc2 owns tsi108, but the new manufactured board has tsi109.
Roy
^ permalink raw reply
* Re: Latest paulus.git PCI broken on mpc8540?
From: Benjamin Herrenschmidt @ 2007-11-16 5:35 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-embedded
In-Reply-To: <4E0EFED3-8697-4768-9D89-A2443AEC82A5@kernel.crashing.org>
On Thu, 2007-11-15 at 22:37 -0600, Kumar Gala wrote:
> > PCI: Probing PCI hardware
> > PCI: Cannot allocate resource region 0 of device 0000:00:12.0
> > PCI: Cannot allocate resource region 1 of device 0000:00:12.0
> > PCI: Cannot allocate resource region 2 of device 0000:00:12.0
> > PCI: Cannot allocate resource region 3 of device 0000:00:12.0
> > PCI: Cannot allocate resource region 4 of device 0000:00:12.0
> > PCI: Cannot allocate resource region 0 of device 0000:00:14.0
> > PCI: Cannot allocate resource region 2 of device 0000:00:14.0
>
> this isn't really an error. Its more of a warning, the kernel will
> try and allocate these later and I'm guessing based on what you are
> seeing it succeeded.
>
> Benh, can we possibly change these messages in pci_32.c?
Heh, well, I've been working on 44x PCI lately and got annoyed by the
exact same messages, though I'm still pondering what would be a better
replacement.
Ben
^ permalink raw reply
* Re: Latest paulus.git PCI broken on mpc8540?
From: Kumar Gala @ 2007-11-16 4:37 UTC (permalink / raw)
To: Clemens Koller; +Cc: linuxppc-embedded
In-Reply-To: <473C7FCC.7050307@anagramm.de>
On Nov 15, 2007, at 11:20 AM, Clemens Koller wrote:
> Hi there!
>
> I try to use the latest Linux-2.6.24-rc2-ge6a5c27f from paulus.git
> for my mpc8540ads compatible board.
>
> $ dmesg contains some nasty messages, which look like something is
> wrong.
>
> PCI: Probing PCI hardware
> PCI: Cannot allocate resource region 0 of device 0000:00:12.0
> PCI: Cannot allocate resource region 1 of device 0000:00:12.0
> PCI: Cannot allocate resource region 2 of device 0000:00:12.0
> PCI: Cannot allocate resource region 3 of device 0000:00:12.0
> PCI: Cannot allocate resource region 4 of device 0000:00:12.0
> PCI: Cannot allocate resource region 0 of device 0000:00:14.0
> PCI: Cannot allocate resource region 2 of device 0000:00:14.0
this isn't really an error. Its more of a warning, the kernel will
try and allocate these later and I'm guessing based on what you are
seeing it succeeded.
Benh, can we possibly change these messages in pci_32.c?
- k
^ permalink raw reply
* hangs after "Freeing unused kernel memory"
From: Siva Prasad @ 2007-11-16 0:00 UTC (permalink / raw)
To: linuxppc-embedded, linuxppc-dev
Hi,
This sounds like a familiar problem, but could not get answers in posts
that came up in google search.
My system hangs after printing the message "Freeing unused kernel
memory". It should execute init after that, but not sure what exactly is
happening. Appreciate if some one can throw few ideas to try out.
Seems it is actually hanging when it makes the call "
run_init_process(ramdisk_execute_command)" in init/main.c
System: 8641D
Kernel: 2.6.19
Vitesse VSC8244: Registered new driver
Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
ide: Assuming 33MHz system bus speed for PIO modes; override with
idebus=3Dxx
bus pci: add driver ALI15x3_IDE
bus ide: add driver ide-disk
bus ide: add driver ide-cdrom
bus scsi: add driver sd
bus pci: add driver ahci
bus platform: add driver fsl-i2c
bus i2c: add driver eeprom
TCP cubic registered
Initializing XFRM netlink socket
NET: Registered protocol family 1
NET: Registered protocol family 10
IPv6 over IPv4 tunneling driver
NET: Registered protocol family 17
Freeing unused kernel memory: 140k init
Thanks
Siva
^ permalink raw reply
* Re: 2.6.24-rc1 on PPC64: machine check exception
From: Paul Mackerras @ 2007-11-15 23:46 UTC (permalink / raw)
To: Vaidyanathan Srinivasan; +Cc: linuxppc, Anton Blanchard, lkml
In-Reply-To: <473C7B16.3050700@linux.vnet.ibm.com>
Vaidyanathan Srinivasan writes:
> This patch fixed the problem. I am able to run and profile ebizzy on 128-way
> PPC64. However this fix is not included in 2.6.24-rc2 as well.
> I will watch for inclusion of this fix in 2.6.24.
It's upstream in Linus' tree now, so it will be in -rc3.
Paul.
^ permalink raw reply
* [PATCH 3/3]: powerpc/eeh: report errors as soon as possible.
From: Linas Vepstas @ 2007-11-15 18:58 UTC (permalink / raw)
To: Paul Mackerras; +Cc: munsone, linuxppc-dev, Sandra Rhodes
In-Reply-To: <20071115185420.GF18745@austin.ibm.com>
Do not wait for the pci slot status before reporting an error
to the device driver. Some systems may take many seconds to
report the slot status, and this can confuse unsuspecting
device drivers.
Signed-off-by: Linas Vepstas <linas@austin.ibm.com>
----
arch/powerpc/platforms/pseries/eeh_driver.c | 15 ++++++++-------
1 file changed, 8 insertions(+), 7 deletions(-)
Index: linux-2.6.23-rc8-mm1/arch/powerpc/platforms/pseries/eeh_driver.c
===================================================================
--- linux-2.6.23-rc8-mm1.orig/arch/powerpc/platforms/pseries/eeh_driver.c 2007-11-09 17:28:58.000000000 -0600
+++ linux-2.6.23-rc8-mm1/arch/powerpc/platforms/pseries/eeh_driver.c 2007-11-09 17:36:51.000000000 -0600
@@ -354,13 +354,6 @@ struct pci_dn * handle_eeh_events (struc
if (frozen_pdn->eeh_freeze_count > EEH_MAX_ALLOWED_FREEZES)
goto excess_failures;
- /* Get the current PCI slot state. */
- rc = eeh_wait_for_slot_status (frozen_pdn, MAX_WAIT_FOR_RECOVERY*1000);
- if (rc < 0) {
- printk(KERN_WARNING "EEH: Permanent failure\n");
- goto hard_fail;
- }
-
printk(KERN_WARNING
"EEH: This PCI device has failed %d times in the last hour:\n",
frozen_pdn->eeh_freeze_count);
@@ -376,6 +369,14 @@ struct pci_dn * handle_eeh_events (struc
*/
pci_walk_bus(frozen_bus, eeh_report_error, &result);
+ /* Get the current PCI slot state. This can take a long time,
+ * sometimes over 3 seconds for certain systems. */
+ rc = eeh_wait_for_slot_status (frozen_pdn, MAX_WAIT_FOR_RECOVERY*1000);
+ if (rc < 0) {
+ printk(KERN_WARNING "EEH: Permanent failure\n");
+ goto hard_fail;
+ }
+
/* Since rtas may enable MMIO when posting the error log,
* don't post the error log until after all dev drivers
* have been informed.
^ permalink raw reply
* [PATCH 2/3] powerpc: EEH: careful when identifying "empty" slots.
From: Linas Vepstas @ 2007-11-15 18:57 UTC (permalink / raw)
To: Paul Mackerras; +Cc: munsone, linuxppc-dev, Sandra Rhodes
In-Reply-To: <20071115185420.GF18745@austin.ibm.com>
If an "empty" slot is failing, make sure its a permanent failure;
else process the error normally.
Signed-off-by: Linas Vepstas <linas@austin.ibm.com>
----
arch/powerpc/platforms/pseries/eeh.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: linux-2.6.23-rc8-mm1/arch/powerpc/platforms/pseries/eeh.c
===================================================================
--- linux-2.6.23-rc8-mm1.orig/arch/powerpc/platforms/pseries/eeh.c 2007-11-09 16:56:39.000000000 -0600
+++ linux-2.6.23-rc8-mm1/arch/powerpc/platforms/pseries/eeh.c 2007-11-09 17:02:39.000000000 -0600
@@ -548,7 +548,7 @@ int eeh_dn_check_failure(struct device_n
/* Note that config-io to empty slots may fail;
* they are empty when they don't have children. */
- if ((rets[0] == 5) && (dn->child == NULL)) {
+ if ((rets[0] == 5) && (rets[2] == 0) && (dn->child == NULL)) {
false_positives++;
pdn->eeh_false_positives ++;
rc = 0;
^ permalink raw reply
* [PATCH 1/3 v2] powerpc: EEH: work with device endpoint, always
From: Linas Vepstas @ 2007-11-15 18:56 UTC (permalink / raw)
To: Paul Mackerras; +Cc: munsone, linuxppc-dev, Sandra Rhodes
In-Reply-To: <20071115185420.GF18745@austin.ibm.com>
Perform all error checking at the "partitonable endpoint"
of the device.
Signed-off-by: Linas Vepstas <linas@austin.ibm.com>
----
version 2: I still can't get whitespace right the first time ...
arch/powerpc/platforms/pseries/eeh.c | 1 +
1 file changed, 1 insertion(+)
Index: linux-2.6.23-rc8-mm1/arch/powerpc/platforms/pseries/eeh.c
===================================================================
--- linux-2.6.23-rc8-mm1.orig/arch/powerpc/platforms/pseries/eeh.c 2007-11-09 16:54:04.000000000 -0600
+++ linux-2.6.23-rc8-mm1/arch/powerpc/platforms/pseries/eeh.c 2007-11-09 16:56:39.000000000 -0600
@@ -482,6 +482,7 @@ int eeh_dn_check_failure(struct device_n
no_dn++;
return 0;
}
+ dn = find_device_pe(dn);
pdn = PCI_DN(dn);
/* Access to IO BARs might get this far and still not want checking. */
^ permalink raw reply
* [PATCH 1/3] powerpc: EEH: work with device endpoint, always
From: Linas Vepstas @ 2007-11-15 18:54 UTC (permalink / raw)
To: Paul Mackerras; +Cc: munsone, linuxppc-dev, Sandra Rhodes
Perform all error checking at the "partitonable endpoint"
of the device.
Signed-off-by: Linas Vepstas <linas@austin.ibm.com>
----
arch/powerpc/platforms/pseries/eeh.c | 1 +
1 file changed, 1 insertion(+)
Index: linux-2.6.23-rc8-mm1/arch/powerpc/platforms/pseries/eeh.c
===================================================================
--- linux-2.6.23-rc8-mm1.orig/arch/powerpc/platforms/pseries/eeh.c 2007-11-09 16:54:04.000000000 -0600
+++ linux-2.6.23-rc8-mm1/arch/powerpc/platforms/pseries/eeh.c 2007-11-09 16:56:39.000000000 -0600
@@ -482,6 +482,7 @@ int eeh_dn_check_failure(struct device_n
no_dn++;
return 0;
}
+ dn = find_device_pe (dn);
pdn = PCI_DN(dn);
/* Access to IO BARs might get this far and still not want checking. */
^ permalink raw reply
* Re: kernel update on mpc8248 muram definition?
From: Scott Wood @ 2007-11-15 17:30 UTC (permalink / raw)
To: Alan Bennett; +Cc: linuxppc-dev
In-Reply-To: <bfa0697f0711150743t440298cfsbce6f10b6fa39d73@mail.gmail.com>
Alan Bennett wrote:
> While working on i2c support, I've decided to update to a new kernel.
> In the process of doing this, I'm not sure I've properly configured the
> MURAM node to my device tree (i.e. serial is broken again).
You haven't -- you copied muram/data/reg from some other tree, rather
than from resource 2 of cpm/reg in your old tree.
> Also, does
> this, in any way, change the way I offset the early debug transmit
> descriptor address?
No.
> muram@0 {
> #address-cells = <1>;
> #size-cells = <1>;
> ranges = <0 0 10000>;
>
> data@0 {
> compatible = "fsl,cpm-muram-data";
> reg = <0 2000 9800 800>;
> };
> };
muram/data/reg should be <80 1f80 9800 800> for your board.
-Scott
^ permalink raw reply
* Latest paulus.git PCI broken on mpc8540?
From: Clemens Koller @ 2007-11-15 17:20 UTC (permalink / raw)
To: linuxppc-embedded
Hi there!
I try to use the latest Linux-2.6.24-rc2-ge6a5c27f from paulus.git
for my mpc8540ads compatible board.
$ dmesg contains some nasty messages, which look like something is wrong.
PCI: Probing PCI hardware
PCI: Cannot allocate resource region 0 of device 0000:00:12.0
PCI: Cannot allocate resource region 1 of device 0000:00:12.0
PCI: Cannot allocate resource region 2 of device 0000:00:12.0
PCI: Cannot allocate resource region 3 of device 0000:00:12.0
PCI: Cannot allocate resource region 4 of device 0000:00:12.0
PCI: Cannot allocate resource region 0 of device 0000:00:14.0
PCI: Cannot allocate resource region 2 of device 0000:00:14.0
However, the PCI devices just work fine - machine boots and:
$ lspci -vv
00:12.0 Mass storage controller: Promise Technology, Inc. 20269 (rev 02) (prog-if 85)
Subsystem: Promise Technology, Inc. Ultra133TX2
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB-
Status: Cap+ 66MHz+ UDF- FastB2B- ParErr- DEVSEL=slow >TAbort- <TAbort- <MAbort- >SERR- <-
Latency: 128 (1000ns min, 4500ns max), Cache Line Size: 32 bytes
Interrupt: pin A routed to IRQ 18
Region 0: I/O ports at 1000 [size=8]
Region 1: I/O ports at 1008 [size=4]
Region 2: I/O ports at 1010 [size=8]
Region 3: I/O ports at 100c [size=4]
Region 4: I/O ports at 1020 [size=16]
Region 5: Memory at 80000000 (32-bit, non-prefetchable) [size=16K]
Expansion ROM at 000dc000 [disabled] [size=16K]
Capabilities: [60] Power Management version 1
Flags: PMEClk- DSI+ D1+ D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
Kernel driver in use: pata_pdc2027x
00:14.0 Mass storage controller: Promise Technology, Inc. PDC40775 (SATA 300 TX2plus) (rev 02)
Subsystem: Promise Technology, Inc. PDC40775 (SATA 300 TX2plus)
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB-
Status: Cap+ 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR--
Latency: 128 (1000ns min, 4500ns max), Cache Line Size: 32 bytes
Interrupt: pin A routed to IRQ 19
Region 0: I/O ports at 1080 [size=128]
Region 2: I/O ports at 1400 [size=256]
Region 3: Memory at 80004000 (32-bit, non-prefetchable) [size=4K]
Region 4: Memory at 80020000 (32-bit, non-prefetchable) [size=128K]
Expansion ROM at 00080000 [disabled] [size=32K]
Capabilities: [60] Power Management version 2
Flags: PMEClk- DSI+ D1+ D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
Kernel driver in use: sata_promise
Hmm...
I suspect a wrong kernel config or problems with the device tree
(I'm using an unchanged arch/powerpc/boot/dts/mpc8540ads.dts).
My .config is based on the mpc8540_ads_defconfig was attached:
http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20071114/2567627a/attachment-0001.txt
Any ideas?
Thank you,
--
Clemens Koller
__________________________________
R&D Imaging Devices
Anagramm GmbH
Rupert-Mayer-Straße 45/1
Linhof Werksgelände
D-81379 München
Tel.089-741518-50
Fax 089-741518-19
http://www.anagramm-technology.com
^ permalink raw reply
* Re: 2.6.24-rc1 on PPC64: machine check exception
From: Vaidyanathan Srinivasan @ 2007-11-15 17:00 UTC (permalink / raw)
To: Anton Blanchard; +Cc: linuxppc, lkml
In-Reply-To: <472F5C5E.4030607@linux.vnet.ibm.com>
>
>> http://patchwork.ozlabs.org/linuxppc/patch?id=14475
>
> Thanks for pointing me to this patch. I will try out and let you know if
> this fixed the problem.
Hi Anton,
This patch fixed the problem. I am able to run and profile ebizzy on 128-way
PPC64. However this fix is not included in 2.6.24-rc2 as well.
I will watch for inclusion of this fix in 2.6.24.
--Vaidy
^ permalink raw reply
* [PATCH] remove dead MAC_ADBKEYCODES
From: Stanislav Brabec @ 2007-11-15 15:53 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: linux-input, linuxppc-dev
It seems, that current kernel source code contains no traces of
MAC_ADBKEYCODES and no reference to keyboard_sends_linux_keycodes any
more.
Attached patch removes them from configuration files.
Signed-off-by: Stanislav Brabec <sbrabec@suse.cz>
--- a/arch/m68k/Kconfig
+++ b/arch/m68k/Kconfig
@@ -582,20 +582,6 @@ config MAC_HID
depends on INPUT_ADBHID
default y
-config MAC_ADBKEYCODES
- bool "Support for ADB raw keycodes"
- depends on INPUT_ADBHID
- help
- This provides support for sending raw ADB keycodes to console
- devices. This is the default up to 2.4.0, but in future this may be
- phased out in favor of generic Linux keycodes. If you say Y here,
- you can dynamically switch via the
- /proc/sys/dev/mac_hid/keyboard_sends_linux_keycodes
- sysctl and with the "keyboard_sends_linux_keycodes=" kernel
- argument.
-
- If unsure, say Y here.
-
config ADB_KEYBOARD
bool "Support for ADB keyboard (old driver)"
depends on MAC && !INPUT_ADBHID
--- a/arch/m68k/configs/mac_defconfig
+++ b/arch/m68k/configs/mac_defconfig
@@ -678,7 +678,6 @@ CONFIG_LOGO_MAC_CLUT224=y
#
CONFIG_MAC_SCC=y
CONFIG_MAC_HID=y
-CONFIG_MAC_ADBKEYCODES=y
CONFIG_SERIAL_CONSOLE=y
#
--
Best Regards / S pozdravem,
Stanislav Brabec
software developer
---------------------------------------------------------------------
SUSE LINUX, s. r. o. e-mail: sbrabec@suse.cz
Lihovarská 1060/12 tel: +420 284 028 966
190 00 Praha 9 fax: +420 284 028 951
Czech Republic http://www.suse.cz/
^ permalink raw reply
* kernel update on mpc8248 muram definition?
From: Alan Bennett @ 2007-11-15 15:43 UTC (permalink / raw)
To: Scott Wood, linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 5063 bytes --]
Hello;
While working on i2c support, I've decided to update to a new kernel. In
the process of doing this, I'm not sure I've properly configured the MURAM
node to my device tree (i.e. serial is broken again). Also, does this, in
any way, change the way I offset the early debug transmit descriptor
address?
I tried looking at your cpm tree on git.buserror.net, but it seems you've
taken it down?
-Alan
soc@e0000000 {
#address-cells = <1>;
#size-cells = <1>;
device_type = "soc";
compatible = "fsl,mpc8248", "fsl,pq2-soc";
ranges = <00000000 e0000000 00053000>;
// Temporary -- will go away once kernel uses ranges for
get_immrbase().
reg = <e0000000 00053000>;
cpm@119c0 {
#address-cells = <1>;
#size-cells = <1>;
compatible = "fsl,mpc8248-cpm", "fsl,cpm2";
reg = <119c0 30>;
ranges;
muram@0 {
#address-cells = <1>;
#size-cells = <1>;
ranges = <0 0 10000>;
data@0 {
compatible = "fsl,cpm-muram-data";
reg = <0 2000 9800 800>;
};
};
brg@119f0 {
compatible = "fsl,mpc8272-brg",
"fsl,cpm2-brg",
"fsl,cpm-brg";
reg = <119f0 10 115f0 10>;
};
/* Monitor port/SMC1 */
serial@11a80 {
device_type = "serial";
compatible = "fsl,mpc8248-smc-uart",
"fsl,cpm2-smc-uart";
reg = <11a80 20 0 40>;
interrupts = <4 8>;
interrupt-parent = <&PIC>;
fsl,cpm-brg = <7>;
fsl,cpm-command = <1d000000>;
};
/* "Serial" port/SCC1 */
serial@11a00 {
device_type = "serial";
compatible = "fsl,mpc8248-scc-uart",
"fsl,cpm2-scc-uart";
reg = <11a00 20 8000 100>;
interrupts = <28 8>;
interrupt-parent = <&PIC>;
fsl,cpm-brg = <1>;
fsl,cpm-command = <00800000>;
};
/* "Serial" port/SCC4 */
serial@11a60 {
device_type = "serial";
compatible = "fsl,mpc8248-scc-uart",
"fsl,cpm2-scc-uart";
reg = <11a60 20 8300 100>;
interrupts = <2B 8>;
interrupt-parent = <&PIC>;
fsl,cpm-brg = <4>;
fsl,cpm-command = <0CE00000>;
};
ethernet@11300 {
device_type = "network";
compatible = "fsl,mpc8248-fcc-enet",
"fsl,cpm2-fcc-enet";
reg = <11300 20 8400 100 11390 1>;
local-mac-address = [ 00 00 00 00 00 00 ];
interrupts = <20 8>;
interrupt-parent = <&PIC>;
phy-handle = <&PHY0>;
linux,network-index = <0>;
fsl,cpm-command = <12000300>;
};
ethernet@11320 {
device_type = "network";
compatible = "fsl,mpc8248-fcc-enet",
"fsl,cpm2-fcc-enet";
reg = <11320 20 8500 100 113b0 1>;
local-mac-address = [ 00 00 00 00 00 00 ];
interrupts = <21 8>;
interrupt-parent = <&PIC>;
phy-handle = <&PHY1>;
linux,network-index = <1>;
fsl,cpm-command = <16200300>;
};
usb@11b60 {
#address-cells = <1>;
#size-cells = <0>;
compatible = "fsl,mpc8248-usb",
"fsl,cpm2-usb";
reg = <11b60 18 8b00 100>;
interrupt-parent = <&PIC>;
interrupts = <b 8>;
fsl,cpm-command = <2e600000>;
};
i2c@11860 {
compatible = "fsl,mpc8248-i2c",
"fsl,cpm2-i2c",
"fsl,cpm-i2c";
reg = <11860 20 3c80 30>;
interrupts = <1>;
interrupt-parent = <&PIC>;
fsl,cpm-command = <0010>;
};
};
[-- Attachment #2: Type: text/html, Size: 16181 bytes --]
^ permalink raw reply
* Virtex TEMAC ping -s 10000 host, is it working?
From: alex_snippet @ 2007-11-15 15:07 UTC (permalink / raw)
To: linuxppc-embedded
Hi All!
On Virtex 4FX board with TEMAC core, Linux ping working fine, but if s -
parameter set to big values it freezes for ever...
Colleagues please share your experience with ping -s 10000 host.
Do you know what parameters in core or in Linux kernel must be changed to
improve it.
My customer is too hypercritical, he likes to ping :(
I tried to increase LX/TX buffers in core, it increased dead line but there
is no desirable result.
--
View this message in context: http://www.nabble.com/Virtex-TEMAC-ping--s-10000-host%2C-is-it-working--tf4812989.html#a13770288
Sent from the linuxppc-embedded mailing list archive at Nabble.com.
^ permalink raw reply
* RE: MPC5200B: Linux does not recognise the external PCI card
From: Pedro Luis D. L. @ 2007-11-15 14:31 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <200711151521.43047.jbe@pengutronix.de>
------------------------------------------------------------------ Todas mi=
s chorradas alemanas en: http://carcadiz.blogspot.com ---------------------=
---------------------------------------------
----------------------------------------
> From: jbe@pengutronix.de
> To: linuxppc-embedded@ozlabs.org
> Date: Thu, 15 Nov 2007 15:21:41 +0100
> CC: carcadiz@hotmail.com
> Subject: Re: MPC5200B: Linux does not recognise the external PCI card
>=20
> On Thursday 15 November 2007 14:49, Pedro Luis D. L. wrote:
>>> [...]
>>> PCI: Probing PCI hardware
>>> PCI: device 0000:00:18.0 has unknown header type 7f, ignoring.
>>> mpc52xx_pci_fixup_resources() 1057:5809
>>> [...]
>>>
>>> and does not show the external card:
>>
>> Which card?
>=20
> Its a NEC USB 2.0 card.
>=20
>> Is its driver supported by the kernel?
>=20
> I think so.
>=20
>> Is it enabled inside the kernel image?
>=20
> But until the card gets recognised it makes no sense to play with the dri=
ver.
Does it? It looks to me that the kernel detects an attached device to the P=
CI interface, but doesn't know wich one.
May that be the reason why it says "PCI: device 0000:00:18.0 has unknown he=
ader type 7f, ignoring."?
>> Did you add the PCI bridge in platform configuration file? I
>> suppose so if there is a PCI probing test. I added an external ethernet
>> device and had no problem to made it work with 2.6.22 kernel.
>=20
> My kernel is a 2.6.23.1
>=20
> Juergen
Pedro.
_________________________________________________________________
Express yourself instantly with MSN Messenger! Download today it's FREE!
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/=
^ permalink raw reply
* Re: MPC5200B: Linux does not recognise the external PCI card
From: Juergen Beisert @ 2007-11-15 14:21 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <BLU106-W38B9242918AC024D3BEBB6CA820@phx.gbl>
On Thursday 15 November 2007 14:49, Pedro Luis D. L. wrote:
> > [...]
> > PCI: Probing PCI hardware
> > PCI: device 0000:00:18.0 has unknown header type 7f, ignoring.
> > mpc52xx_pci_fixup_resources() 1057:5809
> > [...]
> >
> > and does not show the external card:
>
> Which card?
Its a NEC USB 2.0 card.
> Is its driver supported by the kernel?
I think so.
> Is it enabled inside the kernel image?
But until the card gets recognised it makes no sense to play with the driver.
> Did you add the PCI bridge in platform configuration file? I
> suppose so if there is a PCI probing test. I added an external ethernet
> device and had no problem to made it work with 2.6.22 kernel.
My kernel is a 2.6.23.1
Juergen
^ permalink raw reply
* RE: MPC5200B: Linux does not recognise the external PCI card
From: Pedro Luis D. L. @ 2007-11-15 13:49 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <200711151430.05943.jbe@pengutronix.de>
> From: jbe@pengutronix.de
> To: linuxppc-embedded@ozlabs.org
> Date: Thu, 15 Nov 2007 14:30:05 +0100
> Subject: MPC5200B: Linux does not recognise the external PCI card
>=20
> Hi,
Hello,
> currently I'm trying to activate the PCI bus of my MPC5200B based card. U=
-Boot=20
> outputs:
>=20
> [...]
> PCI: Bus Dev VenId DevId Class Int
> 00 18 1033 0035 0c03 00
> 00 18 1033 0035 0c03 00
> 00 18 1033 00e0 00e0 00
> 00 1a 1057 5809 0680 00
> [...]
>=20
> When I start Linux it outputs:
>=20
> [...]
> PCI: Probing PCI hardware
> PCI: device 0000:00:18.0 has unknown header type 7f, ignoring.
> mpc52xx_pci_fixup_resources() 1057:5809
> [...]
>=20
> and does not show the external card:
Which card? Is its driver supported by the kernel? Is it enabled inside the=
kernel image?
Did you add the PCI bridge in platform configuration file? I suppose so if =
there is a PCI probing test.
I added an external ethernet device and had no problem to made it work with=
2.6.22 kernel.
Pedro.
> # lspci -v
> 00:1a.0 Bridge: Motorola Unknown device 5809
> Flags: bus master, 66MHz, medium devsel, latency 248
> Memory at a0000000 (32-bit, non-prefetchable) [size=3D256K]
> Memory at (32-bit, prefetchable)
>=20
> Any idea what could cause this behavior?
> Could this be an oftree related issue? Or something hardware only related=
?
> The external slot is of 3.3V only type, running at 33 1/3 MHz.
>=20
> If it is an oftree issue, can someone point me to some kind of documentat=
ion,=20
> what data I must provide in the
> pci@0d00 {
> ....
> }
> section?
>=20
> Juergen
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
_________________________________________________________________
Express yourself instantly with MSN Messenger! Download today it's FREE!
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/=
^ permalink raw reply
* Kexec on powerpc
From: marco.stornelli @ 2007-11-15 13:14 UTC (permalink / raw)
To: linuxppc-embedded
Hi all,
I'm using the latest kernel and I need the kexec support for 85xx
processor. When I use the menuconfig with ARCH=ppc and the 85xx and
e500 support, I have the kexec support, but when I use ARCH=powerpc I
haven't it, but I'm selecting the same processor!! Is it a bug in
kconfig? Somebody can explain to me why?
Thanks in advance.
Marco
^ permalink raw reply
* MPC5200B: Linux does not recognise the external PCI card
From: Juergen Beisert @ 2007-11-15 13:30 UTC (permalink / raw)
To: linuxppc-embedded
Hi,
currently I'm trying to activate the PCI bus of my MPC5200B based card. U-Boot
outputs:
[...]
PCI: Bus Dev VenId DevId Class Int
00 18 1033 0035 0c03 00
00 18 1033 0035 0c03 00
00 18 1033 00e0 00e0 00
00 1a 1057 5809 0680 00
[...]
When I start Linux it outputs:
[...]
PCI: Probing PCI hardware
PCI: device 0000:00:18.0 has unknown header type 7f, ignoring.
mpc52xx_pci_fixup_resources() 1057:5809
[...]
and does not show the external card:
# lspci -v
00:1a.0 Bridge: Motorola Unknown device 5809
Flags: bus master, 66MHz, medium devsel, latency 248
Memory at a0000000 (32-bit, non-prefetchable) [size=256K]
Memory at <unassigned> (32-bit, prefetchable)
Any idea what could cause this behavior?
Could this be an oftree related issue? Or something hardware only related?
The external slot is of 3.3V only type, running at 33 1/3 MHz.
If it is an oftree issue, can someone point me to some kind of documentation,
what data I must provide in the
pci@0d00 {
....
}
section?
Juergen
^ permalink raw reply
* Re: [PATCH 1/2] ps3: Prefix all ps3-specific kernel modules with `ps3-'
From: Geert Uytterhoeven @ 2007-11-15 12:53 UTC (permalink / raw)
To: Andrew Morton; +Cc: Linux/PPC Development
In-Reply-To: <Pine.LNX.4.62.0711151152290.19455@pademelon.sonytel.be>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1492 bytes --]
ps3: Prefix ps3-specific kernel modules with `ps3-':
- vuart.ko -> ps3-vuart.ko
- sys-manager.ko -> ps3-sys-manager.ko
Signed-off-by: Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com>
---
As the patch was too big for linuxppc-dev, here's an alternative using `mv'
drivers/ps3/Makefile | 4
5 files changed, 1975 insertions(+), 1975 deletions(-)
mv drivers/ps3/sys-manager.c drivers/ps3/ps3-sys-manager.c
mv drivers/ps3/vuart.c drivers/ps3/ps3-vuart.c
--- a/drivers/ps3/Makefile
+++ b/drivers/ps3/Makefile
@@ -1,6 +1,6 @@
-obj-$(CONFIG_PS3_VUART) += vuart.o
+obj-$(CONFIG_PS3_VUART) += ps3-vuart.o
obj-$(CONFIG_PS3_PS3AV) += ps3av_mod.o
ps3av_mod-objs += ps3av.o ps3av_cmd.o
obj-$(CONFIG_PPC_PS3) += sys-manager-core.o
-obj-$(CONFIG_PS3_SYS_MANAGER) += sys-manager.o
+obj-$(CONFIG_PS3_SYS_MANAGER) += ps3-sys-manager.o
obj-$(CONFIG_PS3_STORAGE) += ps3stor_lib.o
With kind regards,
Geert Uytterhoeven
Software Architect
Sony Network and Software Technology Center Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium
Phone: +32 (0)2 700 8453
Fax: +32 (0)2 700 8622
E-mail: Geert.Uytterhoeven@sonycom.com
Internet: http://www.sony-europe.com/
Sony Network and Software Technology Center Europe
A division of Sony Service Centre (Europe) N.V.
Registered office: Technologielaan 7 · B-1840 Londerzeel · Belgium
VAT BE 0413.825.160 · RPR Brussels
Fortis Bank Zaventem · Swift GEBABEBB08A · IBAN BE39001382358619
^ permalink raw reply
* Re: /sbin/init: error while loading shared libraries: libm.so.6:cannot open shared object file: No such file or directory [Scanned]
From: S. Fricke @ 2007-11-15 12:52 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <1195129440.10980.7.camel@linux-2drc.site>
[-- Attachment #1: Type: text/plain, Size: 1145 bytes --]
Hello,
> I have a problem with booting the uRamdisk image from eldk 4.1 on an
> TQM5200 (MPC5200 CPU) board.
> I have taken the uRamdisk image from the "/eldk/ppc_6xx/images" folder
> and copied it to the flash. After booting the following output came
> after the Kernel boot:
>
> Freeing unused kernel memory: 64k init
> /sbin/init: error while loading shared libraries: libm.so.6: cannot open
> shared object file: No such file or directory
> Kernel panic: Attempted to kill init!
> <0>Rebooting in 1 seconds..
>
>
> An image from eldk 3.1.1 is working fine with the Kernel 2.4.25.
> The files libm.so.6 and libm-2.3.5.so are available in the /lib folder.
>
> Does anyone has an idea, what this could be?
This is a problem of handling the eldk. Please contact the eldk-ml on [1].
[1] http://lists.denx.de/mailman/listinfo/eldk
Bye!
eS.eF.
--
-- S. Fricke ----------------------------- MAILTO:silvio.fricke@gmail.com --
Diplom-Informatiker (FH)
Linux-Entwicklung JABBER: silvio@jabber.ccc.de
----------------------------------------------------------------------------
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox