* Re: [PATCH] PPC: CELLEB - fix potential NULL pointer dereference
From: Cyrill Gorcunov @ 2007-11-28 10:53 UTC (permalink / raw)
To: michael; +Cc: Olof Johansson, PPCML, Paul Mackerras, LKML
In-Reply-To: <1196243333.2109.2.camel@concordia>
On 11/28/07, Michael Ellerman <michael@ellerman.id.au> wrote:
> On Mon, 2007-11-26 at 10:46 +0300, Cyrill Gorcunov wrote:
> > This patch adds checking for NULL value returned to prevent possible
> > NULL pointer dereference.
> > Also two unneeded 'return' are removed.
> >
> > Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com>
> > ---
> > Any comments are welcome.
>
> I guess it's good to be paranoid, but this is a little verbose:
>
> wi0 = of_get_property(node, "device-id", NULL);
> + if (unlikely((!wi0))) {
> + printk(KERN_ERR "PCI: device-id not found.\n");
> + goto error;
> + }
> wi1 = of_get_property(node, "vendor-id", NULL);
> + if (unlikely((!wi1))) {
> + printk(KERN_ERR "PCI: vendor-id not found.\n");
> + goto error;
> + }
> wi2 = of_get_property(node, "class-code", NULL);
> + if (unlikely((!wi2))) {
> + printk(KERN_ERR "PCI: class-code not found.\n");
> + goto error;
> + }
> wi3 = of_get_property(node, "revision-id", NULL);
> + if (unlikely((!wi3))) {
> + printk(KERN_ERR "PCI: revision-id not found.\n");
> + goto error;
> + }
>
> Perhaps instead:
>
> wi0 = of_get_property(node, "device-id", NULL);
> wi1 = of_get_property(node, "vendor-id", NULL);
> wi2 = of_get_property(node, "class-code", NULL);
> wi3 = of_get_property(node, "revision-id", NULL);
>
> if (!wi0 || !wi1 || !wi2 || !wi3) {
> printk(KERN_ERR "PCI: Missing device tree properties.\n");
> goto error;
> }
Hi Michael, yes that is much better (actually I was doubt about what form of
which the checking style to use - your form is much compact but mine does
show where *exactly* the problem appeared). So 'case that is the fake driver
your form is preferred ;) Ishizaki, could you use Michael's part then?
>
>
> cheers
>
> --
> Michael Ellerman
> OzLabs, IBM Australia Development Lab
>
> wwweb: http://michael.ellerman.id.au
> phone: +61 2 6212 1183 (tie line 70 21183)
>
> We do not inherit the earth from our ancestors,
> we borrow it from our children. - S.M.A.R.T Person
>
>
Cyrill
^ permalink raw reply
* Re: pseries (power3) boot hang (pageblock_nr_pages==0)
From: Mel Gorman @ 2007-11-28 10:52 UTC (permalink / raw)
To: Will Schmidt; +Cc: linuxppc-dev, Stephen Rothwell, Linux Memory Management List
In-Reply-To: <1196105757.11297.11.camel@farscape.rchland.ibm.com>
On (26/11/07 13:35), Will Schmidt didst pronounce:
>
> On Wed, 2007-11-21 at 22:03 +0000, Mel Gorman wrote:
> > On (21/11/07 15:55), Will Schmidt didst pronounce:
> > > Hi Folks,
> > >
> > > I imagine this would be properly fixed with something similar to the
> > > change for iSeries.
> >
> > Have you tried with the patch that fixed the iSeries boot problem?
> > Thanks for tracking down the problem to such a specific place.
>
> I had not, but gave this patch a spin this morning, and it does the
> job. :-)
Brilliant.
> I was thinking (without really looking at it), that the
> iseries fix was in platform specific code. Silly me. :-)
>
> So for the record, this patch also fixes power3 pSeries systems.
>
> fwiw:
> Tested-By: Will Schmidt <will_schmidt@vnet.ibm.com>
>
Thanks a lot for reporting and testing Will.
--
Mel Gorman
Part-time Phd Student Linux Technology Center
University of Limerick IBM Dublin Software Lab
^ permalink raw reply
* Re: [PATCH] [POWERPC] Emulate isel (Integer Select) instruction
From: Geert Uytterhoeven @ 2007-11-28 10:49 UTC (permalink / raw)
To: Olof Johansson; +Cc: linuxppc-dev
In-Reply-To: <20071127152317.GA5230@lixom.net>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 11545 bytes --]
On Tue, 27 Nov 2007, Olof Johansson wrote:
> On Tue, Nov 27, 2007 at 03:56:53PM +0100, Geert Uytterhoeven wrote:
> > include/asm-powerpc/emulator.h | 60 ++++++++++++++++++++++++++++++++++++++
>
> This name stood out as being a bit too generic, emulator could mean
> system support for running under some sort of emulator as well. How
> about emulated_ops.h?
Changed.
> > +config DEBUG_WARN_EMULATED
> > + bool "Warn if emulated instructions are used"
> > + depends on DEBUG_KERNEL && SYSFS
> > + help
> > + This option will cause messages to be printed if an instruction is
> > + emulated.
> > + Counters for emulated instruction usages are always available under
> > + /sys/devices/system/cpu/cpu*/emulated/, irrespective of the state
> > + of this option.
>
> How about making it a sysctl instead, so it can be flipped at runtime
> (but default off)?
Converted to a sysctl.
Subject: powerpc: Keep track of emulated instructions
From: Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com>
powerpc: Keep track of emulated instructions
Counters for the various classes of emulated instructions are available under
/sys/devices/system/cpu/cpu*/emulated/.
Optionally (controlled by /proc/sys/kernel/cpu_emulation_warnings),
rate-limited warnings can be printed to the console when instructions are
emulated.
Signed-off-by: Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com>
---
arch/powerpc/kernel/align.c | 17 ++++--
arch/powerpc/kernel/sysfs.c | 100 ++++++++++++++++++++++++++++++++++++-
arch/powerpc/kernel/traps.c | 24 ++++++++
include/asm-powerpc/emulated_ops.h | 52 +++++++++++++++++++
4 files changed, 186 insertions(+), 7 deletions(-)
--- a/arch/powerpc/kernel/align.c
+++ b/arch/powerpc/kernel/align.c
@@ -24,6 +24,7 @@
#include <asm/system.h>
#include <asm/cache.h>
#include <asm/cputable.h>
+#include <asm/emulated_ops.h>
struct aligninfo {
unsigned char len;
@@ -696,8 +697,10 @@ int fix_alignment(struct pt_regs *regs)
areg = dsisr & 0x1f; /* register to update */
#ifdef CONFIG_SPE
- if ((instr >> 26) == 0x4)
+ if ((instr >> 26) == 0x4) {
+ WARN_EMULATE(spe);
return emulate_spe(regs, reg, instr);
+ }
#endif
instr = (dsisr >> 10) & 0x7f;
@@ -731,17 +734,21 @@ int fix_alignment(struct pt_regs *regs)
/* A size of 0 indicates an instruction we don't support, with
* the exception of DCBZ which is handled as a special case here
*/
- if (instr == DCBZ)
+ if (instr == DCBZ) {
+ WARN_EMULATE(dcbz);
return emulate_dcbz(regs, addr);
+ }
if (unlikely(nb == 0))
return 0;
/* Load/Store Multiple instructions are handled in their own
* function
*/
- if (flags & M)
+ if (flags & M) {
+ WARN_EMULATE(multiple);
return emulate_multiple(regs, addr, reg, nb,
flags, instr, swiz);
+ }
/* Verify the address of the operand */
if (unlikely(user_mode(regs) &&
@@ -758,8 +765,10 @@ int fix_alignment(struct pt_regs *regs)
}
/* Special case for 16-byte FP loads and stores */
- if (nb == 16)
+ if (nb == 16) {
+ WARN_EMULATE(fp_pair);
return emulate_fp_pair(regs, addr, reg, flags);
+ }
/* If we are loading, get the data from user space, else
* get it from register values
--- a/arch/powerpc/kernel/sysfs.c
+++ b/arch/powerpc/kernel/sysfs.c
@@ -8,6 +8,7 @@
#include <linux/nodemask.h>
#include <linux/cpumask.h>
#include <linux/notifier.h>
+#include <linux/sysctl.h>
#include <asm/current.h>
#include <asm/processor.h>
@@ -19,6 +20,7 @@
#include <asm/lppaca.h>
#include <asm/machdep.h>
#include <asm/smp.h>
+#include <asm/emulated_ops.h>
static DEFINE_PER_CPU(struct cpu, cpu_devices);
@@ -291,12 +293,101 @@ static struct sysdev_attribute pa6t_attr
};
+#define SYSFS_EMULATED_SETUP(type) \
+DEFINE_PER_CPU(atomic_long_t, emulated_ ## type); \
+static ssize_t show_emulated_ ## type (struct sys_device *dev, \
+ char *buf) \
+{ \
+ struct cpu *cpu = container_of(dev, struct cpu, sysdev); \
+ \
+ return sprintf(buf, "%lu\n", \
+ atomic_long_read(&per_cpu(emulated_ ## type, \
+ cpu->sysdev.id))); \
+} \
+ \
+static struct sysdev_attribute emulated_ ## type ## _attr = { \
+ .attr = { .name = #type, .mode = 0400 }, \
+ .show = show_emulated_ ## type, \
+};
+
+SYSFS_EMULATED_SETUP(dcba);
+SYSFS_EMULATED_SETUP(dcbz);
+SYSFS_EMULATED_SETUP(fp_pair);
+SYSFS_EMULATED_SETUP(mcrxr);
+SYSFS_EMULATED_SETUP(mfpvr);
+SYSFS_EMULATED_SETUP(multiple);
+SYSFS_EMULATED_SETUP(popcntb);
+SYSFS_EMULATED_SETUP(spe);
+SYSFS_EMULATED_SETUP(string);
+#ifdef CONFIG_MATH_EMULATION
+SYSFS_EMULATED_SETUP(math);
+#elif defined(CONFIG_8XX_MINIMAL_FPEMU)
+SYSFS_EMULATED_SETUP(8xx);
+#endif
+
+static struct attribute *emulated_attrs[] = {
+ &emulated_dcba_attr.attr,
+ &emulated_dcbz_attr.attr,
+ &emulated_fp_pair_attr.attr,
+ &emulated_mcrxr_attr.attr,
+ &emulated_mfpvr_attr.attr,
+ &emulated_multiple_attr.attr,
+ &emulated_popcntb_attr.attr,
+ &emulated_spe_attr.attr,
+ &emulated_string_attr.attr,
+#ifdef CONFIG_MATH_EMULATION
+ &emulated_math_attr.attr,
+#elif defined(CONFIG_8XX_MINIMAL_FPEMU)
+ &emulated_8xx_attr.attr,
+#endif
+ NULL
+};
+
+static struct attribute_group emulated_attr_group = {
+ .attrs = emulated_attrs,
+ .name = "emulated"
+};
+
+int sysctl_warn_emulated;
+
+#ifdef CONFIG_SYSCTL
+static ctl_table warn_emulated_ctl_table[]={
+ {
+ .procname = "cpu_emulation_warnings",
+ .data = &sysctl_warn_emulated,
+ .maxlen = sizeof(int),
+ .mode = 0644,
+ .proc_handler = &proc_dointvec,
+ },
+ {}
+};
+
+static ctl_table warn_emulated_sysctl_root[] = {
+ {
+ .ctl_name = CTL_KERN,
+ .procname = "kernel",
+ .mode = 0555,
+ .child = warn_emulated_ctl_table,
+ },
+ {}
+};
+
+static inline void warn_emulated_sysctl_register(void)
+{
+ int res = register_sysctl_table(warn_emulated_sysctl_root);
+ printk("@@@ register_sysctl_table() returned %d\n", res);
+}
+#else /* !CONFIG_SYSCTL */
+static inline void warn_emulated_sysctl_register(void) {}
+#endif /* !CONFIG_SYSCTL */
+
+
static void register_cpu_online(unsigned int cpu)
{
struct cpu *c = &per_cpu(cpu_devices, cpu);
struct sys_device *s = &c->sysdev;
struct sysdev_attribute *attrs, *pmc_attrs;
- int i, nattrs;
+ int i, nattrs, res;
if (!firmware_has_feature(FW_FEATURE_ISERIES) &&
cpu_has_feature(CPU_FTR_SMT))
@@ -339,6 +430,11 @@ static void register_cpu_online(unsigned
if (cpu_has_feature(CPU_FTR_DSCR))
sysdev_create_file(s, &attr_dscr);
+
+ res = sysfs_create_group(&s->kobj, &emulated_attr_group);
+ if (res)
+ pr_warning("Cannot create emulated sysfs group for cpu %u\n",
+ cpu);
}
#ifdef CONFIG_HOTPLUG_CPU
@@ -560,6 +656,8 @@ static int __init topology_init(void)
register_cpu_online(cpu);
}
+ warn_emulated_sysctl_register();
+
return 0;
}
subsys_initcall(topology_init);
--- a/arch/powerpc/kernel/traps.c
+++ b/arch/powerpc/kernel/traps.c
@@ -53,6 +53,7 @@
#include <asm/processor.h>
#endif
#include <asm/kexec.h>
+#include <asm/emulated_ops.h>
#ifdef CONFIG_DEBUGGER
int (*__debugger)(struct pt_regs *regs);
@@ -707,6 +708,13 @@ static int emulate_popcntb_inst(struct p
return 0;
}
+void do_warn_emulate(const char *type)
+{
+ if (printk_ratelimit())
+ pr_warning("%s used emulated %s instruction\n", current->comm,
+ type);
+}
+
static int emulate_instruction(struct pt_regs *regs)
{
u32 instword;
@@ -721,31 +729,38 @@ static int emulate_instruction(struct pt
/* Emulate the mfspr rD, PVR. */
if ((instword & INST_MFSPR_PVR_MASK) == INST_MFSPR_PVR) {
+ WARN_EMULATE(mfpvr);
rd = (instword >> 21) & 0x1f;
regs->gpr[rd] = mfspr(SPRN_PVR);
return 0;
}
/* Emulating the dcba insn is just a no-op. */
- if ((instword & INST_DCBA_MASK) == INST_DCBA)
+ if ((instword & INST_DCBA_MASK) == INST_DCBA) {
+ WARN_EMULATE(dcba);
return 0;
+ }
/* Emulate the mcrxr insn. */
if ((instword & INST_MCRXR_MASK) == INST_MCRXR) {
int shift = (instword >> 21) & 0x1c;
unsigned long msk = 0xf0000000UL >> shift;
+ WARN_EMULATE(mcrxr);
regs->ccr = (regs->ccr & ~msk) | ((regs->xer >> shift) & msk);
regs->xer &= ~0xf0000000UL;
return 0;
}
/* Emulate load/store string insn. */
- if ((instword & INST_STRING_GEN_MASK) == INST_STRING)
+ if ((instword & INST_STRING_GEN_MASK) == INST_STRING) {
+ WARN_EMULATE(string);
return emulate_string_inst(regs, instword);
+ }
/* Emulate the popcntb (Population Count Bytes) instruction. */
if ((instword & INST_POPCNTB_MASK) == INST_POPCNTB) {
+ WARN_EMULATE(popcntb);
return emulate_popcntb_inst(regs, instword);
}
@@ -929,6 +944,8 @@ void SoftwareEmulation(struct pt_regs *r
#ifdef CONFIG_MATH_EMULATION
errcode = do_mathemu(regs);
+ if (errcode >= 0)
+ WARN_EMULATE(math);
switch (errcode) {
case 0:
@@ -950,6 +967,9 @@ void SoftwareEmulation(struct pt_regs *r
#elif defined(CONFIG_8XX_MINIMAL_FPEMU)
errcode = Soft_emulate_8xx(regs);
+ if (errcode >= 0)
+ WARN_EMULATE(8xx);
+
switch (errcode) {
case 0:
emulate_single_step(regs);
--- /dev/null
+++ b/include/asm-powerpc/emulated_ops.h
@@ -0,0 +1,52 @@
+/*
+ * Copyright 2007 Sony Corp.
+ *
+ * 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; version 2 of the License.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ */
+
+#ifndef _ASM_POWERPC_EMULATED_OPS_H
+#define _ASM_POWERPC_EMULATED_OPS_H
+
+#include <linux/percpu.h>
+
+#include <asm/atomic.h>
+
+DECLARE_PER_CPU(atomic_long_t, emulated_dcba);
+DECLARE_PER_CPU(atomic_long_t, emulated_dcbz);
+DECLARE_PER_CPU(atomic_long_t, emulated_fp_pair);
+DECLARE_PER_CPU(atomic_long_t, emulated_mcrxr);
+DECLARE_PER_CPU(atomic_long_t, emulated_mfpvr);
+DECLARE_PER_CPU(atomic_long_t, emulated_multiple);
+DECLARE_PER_CPU(atomic_long_t, emulated_popcntb);
+DECLARE_PER_CPU(atomic_long_t, emulated_spe);
+DECLARE_PER_CPU(atomic_long_t, emulated_string);
+#ifdef CONFIG_MATH_EMULATION
+DECLARE_PER_CPU(atomic_long_t, emulated_math);
+#elif defined(CONFIG_8XX_MINIMAL_FPEMU)
+DECLARE_PER_CPU(atomic_long_t, emulated_8xx);
+#endif
+
+extern int sysctl_warn_emulated;
+extern void do_warn_emulate(const char *type);
+
+#define WARN_EMULATE(type) \
+ do { \
+ atomic_long_inc(&per_cpu(emulated_ ## type, \
+ raw_smp_processor_id())); \
+ if (sysctl_warn_emulated) \
+ do_warn_emulate(#type); \
+ } while (0)
+
+
+#endif /* _ASM_POWERPC_EMULATED_OPS_H */
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: [PATCH 0/3] OF-platform PATA driver
From: Paul Mundt @ 2007-11-28 9:51 UTC (permalink / raw)
To: Anton Vorontsov; +Cc: Arnd Bergmann, Jeff Garzik, linux-ide, linuxppc-dev
In-Reply-To: <20071127153708.GA12490@localhost.localdomain>
On Tue, Nov 27, 2007 at 06:37:08PM +0300, Anton Vorontsov wrote:
> Here is the second spin of the OF-platform PATA driver and
> related patches.
>
So either the patches are missing, or I wasn't CC'ed on them. I'm going
to go out on a limb and assume the latter. If you wish me to Ack them,
I'm not going to start grovelling around list archives trying to find the
relevant posts.
This is now the second time this has happened, the first time I was only
made aware of this work as Jeff forwarded them along. CC'ing the authors
of code you are changing shouldn't be a cryptic requirement we have to
spell out in SubmittingPatches or so, especially if you're soliciting
Acked-bys. Please fix your development methodology, thanks.
^ permalink raw reply
* Re: [PATCH] PPC: CELLEB - fix potential NULL pointer dereference
From: Michael Ellerman @ 2007-11-28 9:48 UTC (permalink / raw)
To: Cyrill Gorcunov; +Cc: Olof Johansson, PPCML, Paul Mackerras, LKML
In-Reply-To: <aa79d98a0711252346m583b652bocf72e11077da352e@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1828 bytes --]
On Mon, 2007-11-26 at 10:46 +0300, Cyrill Gorcunov wrote:
> This patch adds checking for NULL value returned to prevent possible
> NULL pointer dereference.
> Also two unneeded 'return' are removed.
>
> Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com>
> ---
> Any comments are welcome.
I guess it's good to be paranoid, but this is a little verbose:
wi0 = of_get_property(node, "device-id", NULL);
+ if (unlikely((!wi0))) {
+ printk(KERN_ERR "PCI: device-id not found.\n");
+ goto error;
+ }
wi1 = of_get_property(node, "vendor-id", NULL);
+ if (unlikely((!wi1))) {
+ printk(KERN_ERR "PCI: vendor-id not found.\n");
+ goto error;
+ }
wi2 = of_get_property(node, "class-code", NULL);
+ if (unlikely((!wi2))) {
+ printk(KERN_ERR "PCI: class-code not found.\n");
+ goto error;
+ }
wi3 = of_get_property(node, "revision-id", NULL);
+ if (unlikely((!wi3))) {
+ printk(KERN_ERR "PCI: revision-id not found.\n");
+ goto error;
+ }
Perhaps instead:
wi0 = of_get_property(node, "device-id", NULL);
wi1 = of_get_property(node, "vendor-id", NULL);
wi2 = of_get_property(node, "class-code", NULL);
wi3 = of_get_property(node, "revision-id", NULL);
if (!wi0 || !wi1 || !wi2 || !wi3) {
printk(KERN_ERR "PCI: Missing device tree properties.\n");
goto error;
}
cheers
--
Michael Ellerman
OzLabs, IBM Australia Development Lab
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Getting physical memory information from /proc/iomem
From: Rajasekaran Periyasamy @ 2007-11-28 6:32 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1.1: Type: text/plain, Size: 1580 bytes --]
Hi,
I have a MPC7447A board running linux 2.6.21. I want to get the physical RAM layout from /proc/iomem, but it is not proper as of x86 platform. Here is the output of my target's /proc/iomem.
[root@rootfs ~]# cat /proc/iomem
80000000-87ffffff : PCI hose 0 MEM Space 0
86900000-869fffff : 0000:00:02.2
86a00000-86afffff : 0000:00:02.2
.
.
87f00000-87f7ffff : 0000:00:01.0
87ffffc0-87ffffff : 0000:00:01.0
88000000-8fffffff : PCI hose 1 MEM Space 0
8d3fe000-8d3fefff : 0001:01:05.2
8d3ff000-8d3fffff : 0001:01:05.1
.
.
8e000000-8effffff : 0001:01:04.0
8f800000-8fffffff : 0001:01:04.0
fbe02000-fbe03fff : ethernet shared base
fbe04000-fbe04c17 : sdma 0 base
fbe04000-fbe04c17 : sdma_regs
fbe06000-fbe06c17 : sdma 1 base
fbe06000-fbe06c17 : sdma_regs
fbe08000-fbe08037 : mpsc 0 base
fbe08000-fbe08037 : mpsc_regs
fbe09000-fbe09037 : mpsc 1 base
fbe09000-fbe09037 : mpsc_regs
fbe0b200-fbe0b207 : brg 0 base
fbe0b200-fbe0b207 : brg_regs
fbe0b208-fbe0b20f : brg 1 base
fbe0b208-fbe0b20f : brg_regs
fbe0b400-fbe0b40b : mpsc routing base
fbe0b400-fbe0b40b : mpsc_routing_regs
fbe0b800-fbe0b883 : sdma intr base
fbe0b800-fbe0b883 : sdma_intr_regs
fbe0c000-fbe0c01f : mv64xxx i2c base
fbe0c000-fbe0c01f : mv64xxx_i2c adapter
ff000000-ffffffff : physmap-flash.0
ff000000-ffffffff : physmap-flash.0
Can you please anybody tell me how to interpret this to get physical RAM addresses. Or is there any patch available to get the details of System RAM from /proc/iomem ??
Thanks in advance,
Rajasekaran.P
[-- Attachment #1.2: Type: text/html, Size: 2246 bytes --]
^ permalink raw reply
* Re: [PATCH] PPC: CELLEB - fix potential NULL pointer dereference
From: Ishizaki Kou @ 2007-11-28 8:52 UTC (permalink / raw)
To: gorcunov; +Cc: olof, linuxppc-dev, paulus, linux-kernel
In-Reply-To: <aa79d98a0711252346m583b652bocf72e11077da352e@mail.gmail.com>
> This patch adds checking for NULL value returned to prevent possible
> NULL pointer dereference.
> Also two unneeded 'return' are removed.
>
> Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com>
Thanks, I tested your patch and it works.
My original code supposes that the device-tree is provided correctly,
so I omited such checks. (Sorry, it should have been commented.)
Should we check more strictly like your patch?
Best regards,
Kou Ishizaki
^ permalink raw reply
* Re: PPC upstream kernel ignored DABR bug
From: Jan Kratochvil @ 2007-11-28 8:59 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linuxppc-dev, Paul Mackerras, Roland McGrath
In-Reply-To: <200711272335.36981.arnd@arndb.de>
On Tue, 27 Nov 2007 23:35:36 +0100, Arnd Bergmann wrote:
> On Monday 26 November 2007, Jan Kratochvil wrote:
> > Hi,
> >
> > this testcase:
> > http://people.redhat.com/jkratoch/dabr-lost.c
> >
> > reproduces a PPC DABR kernel bug. The variable `variable' should not get
> > modified as the thread modifying it should be caught by its DABR:
> >
> > $ ./dabr-lost
> > TID 30914: DABR 0x10012a77 NIP 0x80f6ebb318
> > TID 30915: DABR 0x10012a77 NIP 0x80f6ebb318
> > TID 30916: DABR 0x10012a77 NIP 0x80f6ebb318
> > TID 30914: hitting the variable
> > TID 30915: hitting the variable
> > TID 30916: hitting the variable
> > variable found = 30916, caught TID = 30914
> > TID 30916: DABR 0x10012a77
> > Variable got modified by a thread which has DABR still set!
> >
>
> This sounds like a bug recently reported by Uli Weigand. BenH
> said he'd take a look, but it probably fell under the table.
> The problem found by Uli is that on certain processors (Cell/B.E.
> in his case), the DABRX register needs to be set in order for
> the DABR to take effect.
Please be aware DABR works fine if the same code runs just 1 (always) or
2 (sometimes) threads. It starts failing with too many threads running:
$ ./dabr-lost
TID 32725: DABR 0x1001279f NIP 0xfecf41c
TID 32726: DABR 0x1001279f NIP 0xfecf41c
TID 32725: hitting the variable
variable found = -1, caught TID = 32725
TID 32726: hitting the variable
variable found = -1, caught TID = 32726
The kernel bug did not get reproduced - increase THREADS.
As I did not find any code in that kernel touching DABRX its value should not
be dependent on the number of threads running.
Regards,
Lace
^ permalink raw reply
* Re: Device tree and /proc/iomem question
From: Kumar Gala @ 2007-11-28 7:02 UTC (permalink / raw)
To: robert lazarski; +Cc: linuxppc-embedded
In-Reply-To: <f87675ee0711261026k65d2d4e3pe74697abbc39930e@mail.gmail.com>
On Nov 26, 2007, at 12:26 PM, robert lazarski wrote:
> Hi all, I'm using a recent pull of the paulus tree 2.6.24RC2 on my
> custom 85xx board. I'm trying to test my PCI1, PCI2 and PCIe . My
> device tree for PCI is:
>
> pci@8000 {
> compatible = "fsl,mpc8540-pci";
> device_type = "pci";
> interrupt-map-mask = <f800 0 0 7>;
> interrupt-map = <
>
> /* IDSEL 0x11 J17 Slot 1 */
> 8800 0 0 1 &mpic 2 1
> 8800 0 0 2 &mpic 3 1
> 8800 0 0 3 &mpic 4 1
> 8800 0 0 4 &mpic 1 1
>
> /* IDSEL 0x12 J16 Slot 2 */
>
> 9000 0 0 1 &mpic 3 1
> 9000 0 0 2 &mpic 4 1
> 9000 0 0 3 &mpic 2 1
> 9000 0 0 4 &mpic 1 1>;
>
> interrupt-parent = <&mpic>;
> interrupts = <18 2>;
> bus-range = <0 ff>;
> ranges = <02000000 0 80000000 80000000 0 20000000
> 01000000 0 00000000 e2000000 0 00100000>;
> clock-frequency = <3f940aa>;
> #interrupt-cells = <1>;
> #size-cells = <2>;
> #address-cells = <3>;
> reg = <8000 1000>;
> };
>
> pci@c000 {
> compatible = "fsl,mpc8540-pci";
> device_type = "pci";
> interrupt-map-mask = <f800 0 0 7>;
> interrupt-map = <
>
> /* IDSEL 0x11 J17 Slot 1 */
> 8800 0 0 1 &mpic 2 1
> 8800 0 0 2 &mpic 3 1
> 8800 0 0 3 &mpic 4 1
> 8800 0 0 4 &mpic 1 1
>
> /* IDSEL 0x12 J16 Slot 2 */
>
> 9000 0 0 1 &mpic 3 1
> 9000 0 0 2 &mpic 4 1
> 9000 0 0 3 &mpic 2 1
> 9000 0 0 4 &mpic 1 1>;
>
> interrupt-parent = <&mpic>;
> interrupts = <18 2>;
> bus-range = <0 ff>;
> ranges = <02000000 0 c0000000 c0000000 0 20000000
> 01000000 0 00000000 e2800000 0 00100000>;
> clock-frequency = <3f940aa>;
> #interrupt-cells = <1>;
> #size-cells = <2>;
> #address-cells = <3>;
> reg = <c000 1000>;
> };
>
> pcie@a000 {
> compatible = "fsl,mpc8548-pcie";
> device_type = "pci";
> #interrupt-cells = <1>;
> #size-cells = <2>;
> #address-cells = <3>;
> reg = <a000 1000>;
> bus-range = <0 ff>;
> ranges = <02000000 0 a0000000 a0000000 0 20000000
> 01000000 0 00000000 e3000000 0 00100000>;
> clock-frequency = <1fca055>;
> interrupt-parent = <&mpic>;
> interrupts = <19 2>;
> interrupt-map-mask = <f800 0 0 7>;
> interrupt-map = <
> /* IDSEL 0x0 */
> 0000 0 0 1 &mpic 0 1
> 0000 0 0 2 &mpic 1 1
> 0000 0 0 3 &mpic 2 1
> 0000 0 0 4 &mpic 3 1
> >;
> };
Take a look at the device trees in the kernel source. You'll see we
moved PCI around so its at the root level. Not sure if that's your
issue.
> I see all the above in /proc/device-tree/soc8548@e0000000 when booting
> the kernel. I double checked my memory mapping in u-boot and it
> appears to match my device tree. Yet I don't see any pci here:
>
> root:~> cat /proc/iomem
> e0004500-e0004507 : serial
> e0004600-e0004607 : serial
> e0024000-e0024fff : ethernet
> e0024520-e002453f : mdio
> e0025000-e0025fff : ethernet
> e0026000-e0026fff : ethernet
> e0027000-e0027fff : ethernet
>
> cat /proc/bus/pci/devices shows nothing though I have a card in PCI1,
> and all I see from dmesg is "PCI: Probing PCI hardware" . Any ideas?
It seems like its not even really probing or finding the buses.
Can you post what your board/platform code looks like?
- k
^ permalink raw reply
* [BUG] 2.6.24-rc3-git2 softlockup detected
From: Kamalesh Babulal @ 2007-11-28 6:29 UTC (permalink / raw)
To: LKML, linuxppc-dev, Andy Whitcroft, Balbir Singh
Hi,
Soft lockup is detected while bootup with 2.6.24-rc3-git2 on powerbox
BUG: soft lockup - CPU#1 stuck for 11s! [insmod:375]
NIP: c00000000002f02c LR: d0000000001414fc CTR: c00000000002f018
REGS: c00000077cbef0b0 TRAP: 0901 Not tainted (2.6.24-rc3-git2-autotest)
MSR: 8000000000009032 <EE,ME,IR,DR> CR: 24022088 XER: 00000000
TASK = c00000077cbd8000[375] 'insmod' THREAD: c00000077cbec000 CPU: 1
GPR00: d0000000001414fc c00000077cbef330 c00000000052b930 d000080080002014
GPR04: d00008008000202c 0000000000000000 c00000077ca1cb00 d00000000014ce54
GPR08: c00000077ca1c63c 0000000000000000 000000000000002a c00000000002f018
GPR12: d000000000143610 c000000000473d00
NIP [c00000000002f02c] .ioread8+0x14/0x60
LR [d0000000001414fc] .sym_hcb_attach+0x1188/0x1378 [sym53c8xx]
Call Trace:
[c00000077cbef330] [c00000077cbef3c0] 0xc00000077cbef3c0 (unreliable)
[c00000077cbef3a0] [d0000000001414fc] .sym_hcb_attach+0x1188/0x1378 [sym53c8xx]
[c00000077cbef470] [d0000000001395f8] .sym2_probe+0x700/0x99c [sym53c8xx]
[c00000077cbef710] [c0000000001bc118] .pci_device_probe+0x124/0x1b0
[c00000077cbef7b0] [c000000000221138] .driver_probe_device+0x144/0x20c
[c00000077cbef850] [c000000000221450] .__driver_attach+0xcc/0x154
[c00000077cbef8e0] [c00000000021ff94] .bus_for_each_dev+0x7c/0xd4
[c00000077cbef9a0] [c000000000220e9c] .driver_attach+0x28/0x40
[c00000077cbefa20] [c0000000002204d8] .bus_add_driver+0x90/0x228
[c00000077cbefac0] [c000000000221858] .driver_register+0x94/0xb0
[c00000077cbefb40] [c0000000001bc430] .__pci_register_driver+0x6c/0xcc
[c00000077cbefbe0] [d000000000143428] .sym2_init+0x108/0x15b0 [sym53c8xx]
[c00000077cbefc80] [c00000000008ce80] .sys_init_module+0x17c4/0x1958
[c00000077cbefe30] [c00000000000872c] syscall_exit+0x0/0x40
Instruction dump:
60000000 786b0420 38210070 7d635b78 e8010010 7c0803a6 4e800020 7c0802a6
f8010010 f821ff91 7c0004ac 89230000 <0c090000> 4c00012c 79290620 2f8900ff
--
Thanks & Regards,
Kamalesh Babulal,
Linux Technology Center,
IBM, ISTL.
^ permalink raw reply
* Re: Unable to Read PPC440EPx Board ID thru Board Control and Status Registers (BCSR)
From: Dell Query @ 2007-11-28 6:38 UTC (permalink / raw)
To: Josh Boyer, linuxppc-embedded
In-Reply-To: <20071127212548.3efd39e9@vader.jdub.homelinux.org>
[-- Attachment #1: Type: text/plain, Size: 1768 bytes --]
Oh is it 0x1C0002000?
Where can I get the document? What I have is 0xC0002000 from ep440xc_um_amcc.pdf file that I get from the accompanying PPC440EPx resource CD.
Thanks!
dell
Josh Boyer <jwboyer@gmail.com> wrote: On Tue, 27 Nov 2007 02:47:45 -0800 (PST)
Dell Query wrote:
> Hi,
>
> I am creating a simple program which will try to read the board ID of the PPC440EPx thru BCSR but when I load it, it gives me "Data Read PLB Error".
>
> I am not sure if I missed out something.
>
> I would really appreciate it if somebody could help me on this.
>
> I have posted the source code below, as well as the complete message.
>
> Many thanks!
>
> SOURCE CODE:
> ----------------------------------------------------------------------
> #include
> #include
> #include
> #include
> #include
> #include
> #include
> #include
> #include
> #include
> #include
> #include
> #include
>
> MODULE_LICENSE("GPL");
>
> #define BCSR_BASE 0xC0002000
This is wrong. It's 0x1C0002000.
> #define BCSR0 0
> #define BCSR1 1
> #define BCSR2 2
>
> #define USER_LED 0x2
> #define SIZE_TO_MAP 10
>
> #define LED_ON 0
>
> uint __iomem *bcsrbase = NULL;
>
> static int __init initFunction(void) {
> uint tmp;
> printk("<1> Calling init function.\n");
> printk("<1> bcsrbase value %p...\n",bcsrbase);
> printk("<1> Remapping %x...\n",BCSR_BASE);
> /*map*/
> bcsrbase = ioremap(BCSR_BASE, SIZE_TO_MAP);
Since this seems to be arch/ppc, use ioremap64.
josh
_______________________________________________
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
---------------------------------
Never miss a thing. Make Yahoo your homepage.
[-- Attachment #2: Type: text/html, Size: 2574 bytes --]
^ permalink raw reply
* Re: [BUG] 2.6.24-rc3-git2 softlockup detected
From: Andrew Morton @ 2007-11-28 6:53 UTC (permalink / raw)
To: Kamalesh Babulal
Cc: linux-scsi, LKML, Rafael J. Wysocki, linuxppc-dev, Andy,
Balbir Singh
In-Reply-To: <474D0AAC.5010005@linux.vnet.ibm.com>
On Wed, 28 Nov 2007 11:59:00 +0530 Kamalesh Babulal <kamalesh@linux.vnet.ibm.com> wrote:
> Hi,
(cc linux-scsi, for sym53c8xx)
> Soft lockup is detected while bootup with 2.6.24-rc3-git2 on powerbox
I assume this is a post-2.6.23 regression?
> BUG: soft lockup - CPU#1 stuck for 11s! [insmod:375]
> NIP: c00000000002f02c LR: d0000000001414fc CTR: c00000000002f018
> REGS: c00000077cbef0b0 TRAP: 0901 Not tainted (2.6.24-rc3-git2-autotest)
> MSR: 8000000000009032 <EE,ME,IR,DR> CR: 24022088 XER: 00000000
> TASK = c00000077cbd8000[375] 'insmod' THREAD: c00000077cbec000 CPU: 1
> GPR00: d0000000001414fc c00000077cbef330 c00000000052b930 d000080080002014
> GPR04: d00008008000202c 0000000000000000 c00000077ca1cb00 d00000000014ce54
> GPR08: c00000077ca1c63c 0000000000000000 000000000000002a c00000000002f018
> GPR12: d000000000143610 c000000000473d00
> NIP [c00000000002f02c] .ioread8+0x14/0x60
> LR [d0000000001414fc] .sym_hcb_attach+0x1188/0x1378 [sym53c8xx]
> Call Trace:
> [c00000077cbef330] [c00000077cbef3c0] 0xc00000077cbef3c0 (unreliable)
> [c00000077cbef3a0] [d0000000001414fc] .sym_hcb_attach+0x1188/0x1378 [sym53c8xx]
> [c00000077cbef470] [d0000000001395f8] .sym2_probe+0x700/0x99c [sym53c8xx]
> [c00000077cbef710] [c0000000001bc118] .pci_device_probe+0x124/0x1b0
> [c00000077cbef7b0] [c000000000221138] .driver_probe_device+0x144/0x20c
> [c00000077cbef850] [c000000000221450] .__driver_attach+0xcc/0x154
> [c00000077cbef8e0] [c00000000021ff94] .bus_for_each_dev+0x7c/0xd4
> [c00000077cbef9a0] [c000000000220e9c] .driver_attach+0x28/0x40
> [c00000077cbefa20] [c0000000002204d8] .bus_add_driver+0x90/0x228
> [c00000077cbefac0] [c000000000221858] .driver_register+0x94/0xb0
> [c00000077cbefb40] [c0000000001bc430] .__pci_register_driver+0x6c/0xcc
> [c00000077cbefbe0] [d000000000143428] .sym2_init+0x108/0x15b0 [sym53c8xx]
> [c00000077cbefc80] [c00000000008ce80] .sys_init_module+0x17c4/0x1958
> [c00000077cbefe30] [c00000000000872c] syscall_exit+0x0/0x40
> Instruction dump:
> 60000000 786b0420 38210070 7d635b78 e8010010 7c0803a6 4e800020 7c0802a6
> f8010010 f821ff91 7c0004ac 89230000 <0c090000> 4c00012c 79290620 2f8900ff
I see no obvious lockup sites near the end of sym_hcb_attach(). Maybe it's
being called lots of times from a higher level.. Do the traces all look
the same?
^ permalink raw reply
* Re: [BUG] 2.6.24-rc3-git2 softlockup detected
From: Andrew Morton @ 2007-11-28 7:25 UTC (permalink / raw)
To: Kamalesh Babulal
Cc: linux-scsi, LKML, Rafael J. Wysocki, linuxppc-dev, Andy,
Balbir Singh
In-Reply-To: <474D15FF.5080508@linux.vnet.ibm.com>
On Wed, 28 Nov 2007 12:47:19 +0530 Kamalesh Babulal <kamalesh@linux.vnet.ibm.com> wrote:
> Andrew Morton wrote:
> > On Wed, 28 Nov 2007 11:59:00 +0530 Kamalesh Babulal <kamalesh@linux.vnet.ibm.com> wrote:
> >
> >> Hi,
> >
> > (cc linux-scsi, for sym53c8xx)
> >
> >> Soft lockup is detected while bootup with 2.6.24-rc3-git2 on powerbox
> >
> > I assume this is a post-2.6.23 regression?
> >
> >> BUG: soft lockup - CPU#1 stuck for 11s! [insmod:375]
> >> NIP: c00000000002f02c LR: d0000000001414fc CTR: c00000000002f018
> >> REGS: c00000077cbef0b0 TRAP: 0901 Not tainted (2.6.24-rc3-git2-autotest)
> >> MSR: 8000000000009032 <EE,ME,IR,DR> CR: 24022088 XER: 00000000
> >> TASK = c00000077cbd8000[375] 'insmod' THREAD: c00000077cbec000 CPU: 1
> >> GPR00: d0000000001414fc c00000077cbef330 c00000000052b930 d000080080002014
> >> GPR04: d00008008000202c 0000000000000000 c00000077ca1cb00 d00000000014ce54
> >> GPR08: c00000077ca1c63c 0000000000000000 000000000000002a c00000000002f018
> >> GPR12: d000000000143610 c000000000473d00
> >> NIP [c00000000002f02c] .ioread8+0x14/0x60
> >> LR [d0000000001414fc] .sym_hcb_attach+0x1188/0x1378 [sym53c8xx]
> >> Call Trace:
> >> [c00000077cbef330] [c00000077cbef3c0] 0xc00000077cbef3c0 (unreliable)
> >> [c00000077cbef3a0] [d0000000001414fc] .sym_hcb_attach+0x1188/0x1378 [sym53c8xx]
> >> [c00000077cbef470] [d0000000001395f8] .sym2_probe+0x700/0x99c [sym53c8xx]
> >> [c00000077cbef710] [c0000000001bc118] .pci_device_probe+0x124/0x1b0
> >> [c00000077cbef7b0] [c000000000221138] .driver_probe_device+0x144/0x20c
> >> [c00000077cbef850] [c000000000221450] .__driver_attach+0xcc/0x154
> >> [c00000077cbef8e0] [c00000000021ff94] .bus_for_each_dev+0x7c/0xd4
> >> [c00000077cbef9a0] [c000000000220e9c] .driver_attach+0x28/0x40
> >> [c00000077cbefa20] [c0000000002204d8] .bus_add_driver+0x90/0x228
> >> [c00000077cbefac0] [c000000000221858] .driver_register+0x94/0xb0
> >> [c00000077cbefb40] [c0000000001bc430] .__pci_register_driver+0x6c/0xcc
> >> [c00000077cbefbe0] [d000000000143428] .sym2_init+0x108/0x15b0 [sym53c8xx]
> >> [c00000077cbefc80] [c00000000008ce80] .sys_init_module+0x17c4/0x1958
> >> [c00000077cbefe30] [c00000000000872c] syscall_exit+0x0/0x40
> >> Instruction dump:
> >> 60000000 786b0420 38210070 7d635b78 e8010010 7c0803a6 4e800020 7c0802a6
> >> f8010010 f821ff91 7c0004ac 89230000 <0c090000> 4c00012c 79290620 2f8900ff
> >
> > I see no obvious lockup sites near the end of sym_hcb_attach(). Maybe it's
> > being called lots of times from a higher level.. Do the traces all look
> > the same?
>
> Hi Andrew,
>
> I see this call trace twice and both looks similar and on another reboot
> the following trace is seen twice in different cpu
>
> BUG: soft lockup detected on CPU#3!
> Call Trace:
> [C00000003FEDEDA0] [C000000000010220] .show_stack+0x68/0x1b0 (unreliable)
> [C00000003FEDEE40] [C0000000000A061C] .softlockup_tick+0xf0/0x13c
> [C00000003FEDEEF0] [C000000000072E2C] .run_local_timers+0x1c/0x30
> [C00000003FEDEF70] [C000000000022FA0] .timer_interrupt+0xa8/0x488
> [C00000003FEDF050] [C0000000000034EC] decrementer_common+0xec/0x100
> --- Exception: 901 at .ioread8+0x14/0x60
> LR = .sym_hcb_attach+0x1194/0x1384 [sym53c8xx]
> [C00000003FEDF340] [D0000000002B3BC0] 0xd0000000002b3bc0 (unreliable)
> [C00000003FEDF3B0] [D00000000029A3C0] .sym_hcb_attach+0x1194/0x1384 [sym53c8xx]
> [C00000003FEDF480] [D000000000291D30] .sym2_probe+0x75c/0x9f8 [sym53c8xx]
> [C00000003FEDF710] [C0000000001B65A4] .pci_device_probe+0x13c/0x1dc
> [C00000003FEDF7D0] [C000000000219A0C] .driver_probe_device+0xa0/0x15c
> [C00000003FEDF870] [C000000000219C64] .__driver_attach+0xb4/0x138
> [C00000003FEDF900] [C00000000021913C] .bus_for_each_dev+0x7c/0xd4
> [C00000003FEDF9C0] [C0000000002198B0] .driver_attach+0x28/0x40
> [C00000003FEDFA40] [C000000000218BA4] .bus_add_driver+0x98/0x18c
> [C00000003FEDFAE0] [C00000000021A064] .driver_register+0xa8/0xc4
> [C00000003FEDFB60] [C0000000001B68AC] .__pci_register_driver+0x5c/0xa4
> [C00000003FEDFBF0] [D00000000029C204] .sym2_init+0x104/0x1550 [sym53c8xx]
> [C00000003FEDFC90] [C00000000008D1F4] .sys_init_module+0x1764/0x1998
> [C00000003FEDFE30] [C00000000000869C] syscall_exit+0x0/0x40
>
hm, odd.
Can you look up sym_hcb_attach+0x1194/0x1384 in gdb? Something like
- Enable CONFIG_DEBUG_INFO
- gdb sym53c8xx.o
(gdb) p sym_hcb_attach
<prints 0xsomething>
(gdb) p/x 0xsomething + 0x1194
<prints 0xsomethingelse>
(gdb) l *0xsomethingelse
^ permalink raw reply
* Re: [PATCH 1/2] powerpc: add hugepagesz boot-time parameter
From: Arnd Bergmann @ 2007-11-28 7:26 UTC (permalink / raw)
To: linuxppc-dev, kniht; +Cc: Linux Memory Management List
In-Reply-To: <474CF68E.1040709@us.ibm.com>
On Wednesday 28 November 2007, Jon Tollefson wrote:
> This patch adds the hugepagesz boot-time parameter for ppc64 that lets=20
> you pick the size for your huge pages. =A0The choices available are 64K=20
> and 16M. =A0It defaults to 16M (previously the only choice) if nothing or=
=20
> an invalid choice is specified. =A0Tested 64K huge pages with the=20
> libhugetlbfs 1.2 release with its 'make func' and 'make stress' test=20
> invocations.
How hard would it be to add the 1MB page size that some CPUs support
as well? On systems with small physical memory like the PS3, that
sounds very useful to me.
Arnd <><
^ permalink raw reply
* Re: [BUG] 2.6.24-rc3-git2 softlockup detected
From: Kamalesh Babulal @ 2007-11-28 7:17 UTC (permalink / raw)
To: Andrew Morton
Cc: linux-scsi, LKML, Rafael J. Wysocki, linuxppc-dev, Balbir Singh
In-Reply-To: <20071127225328.9e3f3827.akpm@linux-foundation.org>
Andrew Morton wrote:
> On Wed, 28 Nov 2007 11:59:00 +0530 Kamalesh Babulal <kamalesh@linux.vnet.ibm.com> wrote:
>
>> Hi,
>
> (cc linux-scsi, for sym53c8xx)
>
>> Soft lockup is detected while bootup with 2.6.24-rc3-git2 on powerbox
>
> I assume this is a post-2.6.23 regression?
>
>> BUG: soft lockup - CPU#1 stuck for 11s! [insmod:375]
>> NIP: c00000000002f02c LR: d0000000001414fc CTR: c00000000002f018
>> REGS: c00000077cbef0b0 TRAP: 0901 Not tainted (2.6.24-rc3-git2-autotest)
>> MSR: 8000000000009032 <EE,ME,IR,DR> CR: 24022088 XER: 00000000
>> TASK = c00000077cbd8000[375] 'insmod' THREAD: c00000077cbec000 CPU: 1
>> GPR00: d0000000001414fc c00000077cbef330 c00000000052b930 d000080080002014
>> GPR04: d00008008000202c 0000000000000000 c00000077ca1cb00 d00000000014ce54
>> GPR08: c00000077ca1c63c 0000000000000000 000000000000002a c00000000002f018
>> GPR12: d000000000143610 c000000000473d00
>> NIP [c00000000002f02c] .ioread8+0x14/0x60
>> LR [d0000000001414fc] .sym_hcb_attach+0x1188/0x1378 [sym53c8xx]
>> Call Trace:
>> [c00000077cbef330] [c00000077cbef3c0] 0xc00000077cbef3c0 (unreliable)
>> [c00000077cbef3a0] [d0000000001414fc] .sym_hcb_attach+0x1188/0x1378 [sym53c8xx]
>> [c00000077cbef470] [d0000000001395f8] .sym2_probe+0x700/0x99c [sym53c8xx]
>> [c00000077cbef710] [c0000000001bc118] .pci_device_probe+0x124/0x1b0
>> [c00000077cbef7b0] [c000000000221138] .driver_probe_device+0x144/0x20c
>> [c00000077cbef850] [c000000000221450] .__driver_attach+0xcc/0x154
>> [c00000077cbef8e0] [c00000000021ff94] .bus_for_each_dev+0x7c/0xd4
>> [c00000077cbef9a0] [c000000000220e9c] .driver_attach+0x28/0x40
>> [c00000077cbefa20] [c0000000002204d8] .bus_add_driver+0x90/0x228
>> [c00000077cbefac0] [c000000000221858] .driver_register+0x94/0xb0
>> [c00000077cbefb40] [c0000000001bc430] .__pci_register_driver+0x6c/0xcc
>> [c00000077cbefbe0] [d000000000143428] .sym2_init+0x108/0x15b0 [sym53c8xx]
>> [c00000077cbefc80] [c00000000008ce80] .sys_init_module+0x17c4/0x1958
>> [c00000077cbefe30] [c00000000000872c] syscall_exit+0x0/0x40
>> Instruction dump:
>> 60000000 786b0420 38210070 7d635b78 e8010010 7c0803a6 4e800020 7c0802a6
>> f8010010 f821ff91 7c0004ac 89230000 <0c090000> 4c00012c 79290620 2f8900ff
>
> I see no obvious lockup sites near the end of sym_hcb_attach(). Maybe it's
> being called lots of times from a higher level.. Do the traces all look
> the same?
Hi Andrew,
I see this call trace twice and both looks similar and on another reboot
the following trace is seen twice in different cpu
BUG: soft lockup detected on CPU#3!
Call Trace:
[C00000003FEDEDA0] [C000000000010220] .show_stack+0x68/0x1b0 (unreliable)
[C00000003FEDEE40] [C0000000000A061C] .softlockup_tick+0xf0/0x13c
[C00000003FEDEEF0] [C000000000072E2C] .run_local_timers+0x1c/0x30
[C00000003FEDEF70] [C000000000022FA0] .timer_interrupt+0xa8/0x488
[C00000003FEDF050] [C0000000000034EC] decrementer_common+0xec/0x100
--- Exception: 901 at .ioread8+0x14/0x60
LR = .sym_hcb_attach+0x1194/0x1384 [sym53c8xx]
[C00000003FEDF340] [D0000000002B3BC0] 0xd0000000002b3bc0 (unreliable)
[C00000003FEDF3B0] [D00000000029A3C0] .sym_hcb_attach+0x1194/0x1384 [sym53c8xx]
[C00000003FEDF480] [D000000000291D30] .sym2_probe+0x75c/0x9f8 [sym53c8xx]
[C00000003FEDF710] [C0000000001B65A4] .pci_device_probe+0x13c/0x1dc
[C00000003FEDF7D0] [C000000000219A0C] .driver_probe_device+0xa0/0x15c
[C00000003FEDF870] [C000000000219C64] .__driver_attach+0xb4/0x138
[C00000003FEDF900] [C00000000021913C] .bus_for_each_dev+0x7c/0xd4
[C00000003FEDF9C0] [C0000000002198B0] .driver_attach+0x28/0x40
[C00000003FEDFA40] [C000000000218BA4] .bus_add_driver+0x98/0x18c
[C00000003FEDFAE0] [C00000000021A064] .driver_register+0xa8/0xc4
[C00000003FEDFB60] [C0000000001B68AC] .__pci_register_driver+0x5c/0xa4
[C00000003FEDFBF0] [D00000000029C204] .sym2_init+0x104/0x1550 [sym53c8xx]
[C00000003FEDFC90] [C00000000008D1F4] .sys_init_module+0x1764/0x1998
[C00000003FEDFE30] [C00000000000869C] syscall_exit+0x0/0x40
--
Thanks & Regards,
Kamalesh Babulal,
Linux Technology Center,
IBM, ISTL.
^ permalink raw reply
* [PATCH 2/2] powerpc: make 64K huge pages more reliable
From: Jon Tollefson @ 2007-11-28 5:03 UTC (permalink / raw)
To: linuxppc-dev, Linux Memory Management List
This patch adds reliability to the 64K huge page option by making use of
the PMD for 64K huge pages when base pages are 4k. So instead of a 12
bit pte it would be 7 bit pmd and a 5 bit pte. The pgd and pud offsets
would continue as 9 bits and 7 bits respectively. This will allow the
pgtable to fit in one base page. This patch would have to be applied
after part 1.
Signed-off-by: Jon Tollefson <kniht@linux.vnet.ibm.com>
---
hugetlbpage.c | 53 ++++++++++++++++++++++++++++++++++++++---------------
1 files changed, 38 insertions(+), 15 deletions(-)
diff --git a/arch/powerpc/mm/hugetlbpage.c b/arch/powerpc/mm/hugetlbpage.c
index f4632ad..c6df45b 100644
--- a/arch/powerpc/mm/hugetlbpage.c
+++ b/arch/powerpc/mm/hugetlbpage.c
@@ -30,15 +30,11 @@
#define NUM_LOW_AREAS (0x100000000UL >> SID_SHIFT)
#define NUM_HIGH_AREAS (PGTABLE_RANGE >> HTLB_AREA_SHIFT)
-#ifdef CONFIG_PPC_64K_PAGES
-#define HUGEPTE_INDEX_SIZE (PMD_SHIFT-HPAGE_SHIFT)
-#else
-#define HUGEPTE_INDEX_SIZE (PUD_SHIFT-HPAGE_SHIFT)
-#endif
-#define PTRS_PER_HUGEPTE (1 << HUGEPTE_INDEX_SIZE)
-#define HUGEPTE_TABLE_SIZE (sizeof(pte_t) << HUGEPTE_INDEX_SIZE)
+unsigned int hugepte_shift;
+#define PTRS_PER_HUGEPTE (1 << hugepte_shift)
+#define HUGEPTE_TABLE_SIZE (sizeof(pte_t) << hugepte_shift)
-#define HUGEPD_SHIFT (HPAGE_SHIFT + HUGEPTE_INDEX_SIZE)
+#define HUGEPD_SHIFT (HPAGE_SHIFT + hugepte_shift)
#define HUGEPD_SIZE (1UL << HUGEPD_SHIFT)
#define HUGEPD_MASK (~(HUGEPD_SIZE-1))
@@ -105,7 +101,14 @@ pte_t *huge_pte_offset(struct mm_struct *mm, unsigned long addr)
if (!pmd_none(*pm))
return hugepte_offset((hugepd_t *)pm, addr);
#else
- return hugepte_offset((hugepd_t *)pu, addr);
+ if (HPAGE_SHIFT == HPAGE_SHIFT_64K) {
+ pmd_t *pm;
+ pm = pmd_offset(pu, addr);
+ if (!pmd_none(*pm))
+ return hugepte_offset((hugepd_t *)pm, addr);
+ } else {
+ return hugepte_offset((hugepd_t *)pu, addr);
+ }
#endif
}
}
@@ -133,7 +136,14 @@ pte_t *huge_pte_alloc(struct mm_struct *mm, unsigned long addr)
if (pm)
hpdp = (hugepd_t *)pm;
#else
- hpdp = (hugepd_t *)pu;
+ if (HPAGE_SHIFT == HPAGE_SHIFT_64K) {
+ pmd_t *pm;
+ pm = pmd_alloc(mm, pu, addr);
+ if (pm)
+ hpdp = (hugepd_t *)pm;
+ } else {
+ hpdp = (hugepd_t *)pu;
+ }
#endif
}
@@ -161,7 +171,6 @@ static void free_hugepte_range(struct mmu_gather *tlb, hugepd_t *hpdp)
PGF_CACHENUM_MASK));
}
-#ifdef CONFIG_PPC_64K_PAGES
static void hugetlb_free_pmd_range(struct mmu_gather *tlb, pud_t *pud,
unsigned long addr, unsigned long end,
unsigned long floor, unsigned long ceiling)
@@ -194,7 +203,6 @@ static void hugetlb_free_pmd_range(struct mmu_gather *tlb, pud_t *pud,
pud_clear(pud);
pmd_free_tlb(tlb, pmd);
}
-#endif
static void hugetlb_free_pud_range(struct mmu_gather *tlb, pgd_t *pgd,
unsigned long addr, unsigned long end,
@@ -213,9 +221,15 @@ static void hugetlb_free_pud_range(struct mmu_gather *tlb, pgd_t *pgd,
continue;
hugetlb_free_pmd_range(tlb, pud, addr, next, floor, ceiling);
#else
- if (pud_none(*pud))
- continue;
- free_hugepte_range(tlb, (hugepd_t *)pud);
+ if (HPAGE_SHIFT == HPAGE_SHIFT_64K) {
+ if (pud_none_or_clear_bad(pud))
+ continue;
+ hugetlb_free_pmd_range(tlb, pud, addr, next, floor, ceiling);
+ } else {
+ if (pud_none(*pud))
+ continue;
+ free_hugepte_range(tlb, (hugepd_t *)pud);
+ }
#endif
} while (pud++, addr = next, addr != end);
@@ -538,6 +552,15 @@ void set_huge_psize(int psize)
mmu_psize_defs[psize].shift == HPAGE_SHIFT_64K)) {
HPAGE_SHIFT = mmu_psize_defs[psize].shift;
mmu_huge_psize = psize;
+#ifdef CONFIG_PPC_64K_PAGES
+ hugepte_shift = (PMD_SHIFT-HPAGE_SHIFT);
+#else
+ if (HPAGE_SHIFT == HPAGE_SHIFT_64K)
+ hugepte_shift = (PMD_SHIFT-HPAGE_SHIFT);
+ else
+ hugepte_shift = (PUD_SHIFT-HPAGE_SHIFT);
+#endif
+
} else
HPAGE_SHIFT = 0;
}
^ permalink raw reply related
* [PATCH 1/2] powerpc: add hugepagesz boot-time parameter
From: Jon Tollefson @ 2007-11-28 5:03 UTC (permalink / raw)
To: linuxppc-dev, Linux Memory Management List
This patch adds the hugepagesz boot-time parameter for ppc64 that lets
you pick the size for your huge pages. The choices available are 64K
and 16M. It defaults to 16M (previously the only choice) if nothing or
an invalid choice is specified. Tested 64K huge pages with the
libhugetlbfs 1.2 release with its 'make func' and 'make stress' test
invocations.
This patch requires the patch posted by Mel Gorman that adds
HUGETLB_PAGE_SIZE_VARIABLE; "[PATCH] Fix boot problem with iSeries
lacking hugepage support" on 2007-11-15.
Signed-off-by: Jon Tollefson <kniht@linux.vnet.ibm.com>
---
Documentation/kernel-parameters.txt | 1
arch/powerpc/mm/hash_utils_64.c | 11 +--------
arch/powerpc/mm/hugetlbpage.c | 41 ++++++++++++++++++++++++++++++++++++
include/asm-powerpc/mmu-hash64.h | 1
mm/hugetlb.c | 1
5 files changed, 46 insertions(+), 9 deletions(-)
diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt
index 33121d6..2fc1fb8 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -685,6 +685,7 @@ and is between 256 and 4096 characters. It is defined in the file
See Documentation/isdn/README.HiSax.
hugepages= [HW,X86-32,IA-64] Maximal number of HugeTLB pages.
+ hugepagesz= [HW,IA-64,PPC] The size of the HugeTLB pages.
i8042.direct [HW] Put keyboard port into non-translated mode
i8042.dumbkbd [HW] Pretend that controller can only read data from
diff --git a/arch/powerpc/mm/hash_utils_64.c b/arch/powerpc/mm/hash_utils_64.c
index f09730b..afc044c 100644
--- a/arch/powerpc/mm/hash_utils_64.c
+++ b/arch/powerpc/mm/hash_utils_64.c
@@ -368,18 +368,11 @@ static void __init htab_init_page_sizes(void)
* on what is available
*/
if (mmu_psize_defs[MMU_PAGE_16M].shift)
- mmu_huge_psize = MMU_PAGE_16M;
+ set_huge_psize(MMU_PAGE_16M);
/* With 4k/4level pagetables, we can't (for now) cope with a
* huge page size < PMD_SIZE */
else if (mmu_psize_defs[MMU_PAGE_1M].shift)
- mmu_huge_psize = MMU_PAGE_1M;
-
- /* Calculate HPAGE_SHIFT and sanity check it */
- if (mmu_psize_defs[mmu_huge_psize].shift > MIN_HUGEPTE_SHIFT &&
- mmu_psize_defs[mmu_huge_psize].shift < SID_SHIFT)
- HPAGE_SHIFT = mmu_psize_defs[mmu_huge_psize].shift;
- else
- HPAGE_SHIFT = 0; /* No huge pages dude ! */
+ set_huge_psize(MMU_PAGE_1M);
#endif /* CONFIG_HUGETLB_PAGE */
}
diff --git a/arch/powerpc/mm/hugetlbpage.c b/arch/powerpc/mm/hugetlbpage.c
index 71efb38..f4632ad 100644
--- a/arch/powerpc/mm/hugetlbpage.c
+++ b/arch/powerpc/mm/hugetlbpage.c
@@ -24,6 +24,9 @@
#include <asm/cputable.h>
#include <asm/spu.h>
+#define HPAGE_SHIFT_64K 16
+#define HPAGE_SHIFT_16M 24
+
#define NUM_LOW_AREAS (0x100000000UL >> SID_SHIFT)
#define NUM_HIGH_AREAS (PGTABLE_RANGE >> HTLB_AREA_SHIFT)
@@ -526,6 +529,44 @@ repeat:
return err;
}
+void set_huge_psize(int psize)
+{
+ /* Check that it is a page size supported by the hardware and
+ * that it fits within pagetable limits. */
+ if (mmu_psize_defs[psize].shift && mmu_psize_defs[psize].shift < SID_SHIFT &&
+ (mmu_psize_defs[psize].shift > MIN_HUGEPTE_SHIFT ||
+ mmu_psize_defs[psize].shift == HPAGE_SHIFT_64K)) {
+ HPAGE_SHIFT = mmu_psize_defs[psize].shift;
+ mmu_huge_psize = psize;
+ } else
+ HPAGE_SHIFT = 0;
+}
+
+static int __init hugepage_setup_sz(char *str)
+{
+ unsigned long long size;
+
+ size = memparse(str, &str);
+
+ int shift = __ffs(size);
+ int mmu_psize = -1;
+ switch (shift) {
+ case HPAGE_SHIFT_64K:
+ mmu_psize = MMU_PAGE_64K;
+ break;
+ case HPAGE_SHIFT_16M:
+ mmu_psize = MMU_PAGE_16M;
+ break;
+ }
+ if (mmu_psize >= 0 && mmu_psize_defs[mmu_psize].shift)
+ set_huge_psize(mmu_psize);
+ else
+ printk(KERN_WARNING "Invalid huge page size specified(%i)\n", size);
+
+ return 1;
+}
+__setup("hugepagesz=", hugepage_setup_sz);
+
static void zero_ctor(struct kmem_cache *cache, void *addr)
{
memset(addr, 0, kmem_cache_size(cache));
diff --git a/include/asm-powerpc/mmu-hash64.h b/include/asm-powerpc/mmu-hash64.h
index 82328de..f35c945 100644
--- a/include/asm-powerpc/mmu-hash64.h
+++ b/include/asm-powerpc/mmu-hash64.h
@@ -277,6 +277,7 @@ extern int hash_huge_page(struct mm_struct *mm, unsigned long access,
extern int htab_bolt_mapping(unsigned long vstart, unsigned long vend,
unsigned long pstart, unsigned long mode,
int psize, int ssize);
+extern void set_huge_psize(int psize);
extern void htab_initialize(void);
extern void htab_initialize_secondary(void);
diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index 6121b57..055d232 100644
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -422,6 +422,7 @@ static int __init hugetlb_init(void)
break;
}
max_huge_pages = free_huge_pages = nr_huge_pages = i;
+ printk(KERN_INFO "HugeTLB page size: %ld bytes\n", HPAGE_SIZE);
printk("Total HugeTLB memory allocated, %ld\n", free_huge_pages);
return 0;
}
^ permalink raw reply related
* Re: The question about the high memory support on MPC8360?
From: vijay baskar @ 2007-11-28 4:02 UTC (permalink / raw)
To: Scott Wood; +Cc: 郭劲, linuxppc-embedded
In-Reply-To: <474C4DA9.6000205@freescale.com>
Hi,
"The kernel also allows hardcoded mapping
of IO regions into its virtual address space through the
io_block_mapping interface."
Can u tell me how this is in current arch/powerpc. Also does it mean
that whatever be the size of the ram > 768 MB there is not going to be
much improvement in performance in kernel space irrespective of invoking
CONFIG_HIGHMEM or not?
Also do you think this low mem be enough if i have lots of kernel space
processes each invoking lots of kmallocs. Will there be bottle necks??
Also what alternative do we have if low mem of 768 MB is not enough??
Scott Wood wrote:
> vijay baskar wrote:
>
>> The kernel maps the last 1 GB of the virtual address space one to one
>> to the physical memory.
>
>
> No, it maps 768MB of RAM in this manner.
>
>> This is called the kernel space. After the one
>> to one mapping is done for the available physical memory, the
>> remaining virtual addresses are used for vmalloc and ioremap.
>
>
> And highmem mappings.
>
>> The kernel also allows hardcoded mapping
>> of IO regions into its virtual address space through the
>> io_block_mapping interface.
>
>
> Not in current arch/powerpc kernels.
>
>> Many boards use the block IO mapping to
>> map the CCSRBAR/IMMR into the kernel address space, such that the
>> physical address and the virutal address is the same. Virtual
>> addresses beyond these hardcoded mappings cannot be used by
>> vmalloc/ioremap.
>
>
> And this is why.
>
>> Now as more and more memory is added to the system the addresses
>> available for vmalloc and ioremap gets reduced, and memory allocations
>> start to fail, due to the lack of availability of virtual addresses.
>
>
> How so? The size of lowmem is constant once you reach the threshold,
> as is the size of the highmem mapping area.
>
> What *does* start to fail eventually, if you have a *lot* of highmem,
> is that you run out of lowmem for pagetables and such.
>
> -Scott
>
>
^ permalink raw reply
* of_compat_cmp on various platforms
From: Jon Smirl @ 2007-11-28 3:46 UTC (permalink / raw)
To: PowerPC dev list
Is this right or should it be the same everywhere?
asm-powerpc/prom.h:#define of_compat_cmp(s1, s2, l) strcasecmp((s1), (s2))
asm-sparc/prom.h:#define of_compat_cmp(s1, s2, l) strncmp((s1), (s2), (l))
asm-sparc64/prom.h:#define of_compat_cmp(s1, s2, l) strncmp((s1), (s2), (l))
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: Unable to Read PPC440EPx Board ID thru Board Control and Status Registers (BCSR)
From: Josh Boyer @ 2007-11-28 3:25 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <409454.53699.qm@web45615.mail.sp1.yahoo.com>
On Tue, 27 Nov 2007 02:47:45 -0800 (PST)
Dell Query <dell.query@yahoo.com> wrote:
> Hi,
>
> I am creating a simple program which will try to read the board ID of the PPC440EPx thru BCSR but when I load it, it gives me "Data Read PLB Error".
>
> I am not sure if I missed out something.
>
> I would really appreciate it if somebody could help me on this.
>
> I have posted the source code below, as well as the complete message.
>
> Many thanks!
>
> SOURCE CODE:
> ----------------------------------------------------------------------
> #include <linux/module.h>
> #include <linux/kernel.h>
> #include <linux/ioport.h>
> #include <linux/delay.h>
> #include <linux/init.h>
> #include <linux/interrupt.h>
> #include <linux/platform_device.h>
> #include <asm/irq.h>
> #include <asm/io.h>
> #include <linux/i2c.h>
> #include <linux/i2c-id.h>
> #include <asm/ocp.h>
> #include <asm/ibm4xx.h>
>
> MODULE_LICENSE("GPL");
>
> #define BCSR_BASE 0xC0002000
This is wrong. It's 0x1C0002000.
> #define BCSR0 0
> #define BCSR1 1
> #define BCSR2 2
>
> #define USER_LED 0x2
> #define SIZE_TO_MAP 10
>
> #define LED_ON 0
>
> uint __iomem *bcsrbase = NULL;
>
> static int __init initFunction(void) {
> uint tmp;
> printk("<1> Calling init function.\n");
> printk("<1> bcsrbase value %p...\n",bcsrbase);
> printk("<1> Remapping %x...\n",BCSR_BASE);
> /*map*/
> bcsrbase = ioremap(BCSR_BASE, SIZE_TO_MAP);
Since this seems to be arch/ppc, use ioremap64.
josh
^ permalink raw reply
* Re: Xilinx devicetrees
From: John Williams @ 2007-11-28 0:52 UTC (permalink / raw)
To: Stephen Neuendorffer; +Cc: Michal Simek, linuxppc-embedded
In-Reply-To: <20071128002835.068BE16A005D@mail198-sin.bigfish.com>
Stephen Neuendorffer wrote:
>>From: John Williams [mailto:jwilliams@itee.uq.edu.au]
>>MicroBlaze is a highly configurable CPU in terms of its
>>instruction set,
>>features and so on. To make use of this, it is essential that each
>>kernel image be compiled to match the CPU configuration. While a
>>generic kernel, making use of no features (MUL, DIV, Shift,
>>MSR ops etc)
>>would run on any CPU, performance would be abysmal.
>
> I think the userspace is actually much more critical than the kernel for
> most of these things (with the exception of msrset/msrclr, and the
> barrel shifter perhaps). Unfortunately, even if you implement an
> alternatives-style mechanism for the kernel, you're still hosed for
> userspace.
I haven't benchmarks each option on the kernel - you are right that
shift is a big one, but mul I think is also important, given that every
array access generates an integer multiply,
Once I a big enough system, it's just unfeasible to
> recompile everything anyway. I think this is where autoconfig starts to
> break down.
I'm not sure I agree, here, given that most people building MicroBlaze
systems are doing so with uClinux-dist (or PetaLinux), you can do a full
rebuilt, kernel libs apps, in a couple of minutes. Much shorter than
sythnesis and P&R, that's for sure (and runtime is linear in size,
unlike P&R :)
> It's not nice, I agree. I think the key principle should be that I
> should be able to get a system working as quickly as possible, and I
> might optimize things later. One thing that device trees will allow is
> for *all* the drivers to get compiled in to the kernel, and only as a
> late stage operation does a designer need to start throwing things away.
> Using traps I can easily start with a 'kitchen sink' design, and start
> discarding processor features, relying on the traps. When I get low
> enough down on the performance curve, I can uas an autoconfig-type
> mechanism to regain a little of what I lost by optimizing away the trap
> overhead.
OK, but now we have a kernel dependent on *3* files - a DTS, a
Kconfig.auto, and (indirectly) the bitstream itself.
> Personally, I think the easiest way out of all this is to just have less
> configurability. For microblaze in general, this is too much of a
> restriction, but microblaze used as a control processor running linux,
> there are probably just a few design points that really make sense
> (probably size optimized: no options except maybe msrset/msrclr, and the
> kitchen sink). If we go that far, we don't really need people to ever
> run autoconfig, or kernels, or anything. Especially considering there
> is no easy way of selecting which of the 2^N design points I want
> *anyway*. :)
My experience tells me that if the microblaze can be configured in a
particular way, *someone* will want to do it (and still boot linux on
it!) We still have people building MicroBlaze 3.00 in Spartan2E, with
EDK 6.3. And autoconfig works! Exceptions on/off, MMU on/off (runtime
configurable on that?).
Our ability to plug into the backend design database of EDK presents a
great opportunity - truly automatically configured kernels. I think we
have a responsibility to leverage that power. We are already there
with the static approach, I think we just need to make sure that
persists into the dynamic approach, and that we find a good mix of the two.
There are of course some semantic issues that the EDK cannot
automatically resolve - relative ordering and priority of multiple
peripheral instances for example.
>>One compromise approach might be to have a script in
>>arch/microblaze/scripts, called by the arch Makefile, that
>>cracks open
>>the DT at build time and extracts appropriate cpu flags.
>
> Hmm... interesting idea, although parsing the source is likely
> difficult... It's probably not worth it to go this far, I think. As
> you say, why doesn't autoconfig of today work fine for this.
Well, copying multiple configuration files into the kernel is not ideal.
Surely a little perl or python script would do the trick? DTS syntax
is pretty clean, just find the CPU node and off we go. Multiple CPU,
well... :)
>>Finally, what is the LKML position on DT files going into the kernel
>>source tree?
>
>
> Source .dts go in and get compiled to binary blobs at compile time. The
> 'big' recent controversy is whether the source->binary compiler dtc
> should be mirrored in the Linux tree or not.
OK.
Another thing I suggested to Michal recently, perhaps we need
kernel/lib/libof to store common OF / DT handling code. Much better
than duplicating it accross microblaze and PPC, and maybe other arch's
would also see the light.. That would also add a claim for the DTC to
go in scripts/
John
^ permalink raw reply
* Re: [PATCH 2/3] [libata] pata_of_platform: OF-Platform PATA device driver
From: Stephen Rothwell @ 2007-11-28 0:41 UTC (permalink / raw)
To: Anton Vorontsov; +Cc: linuxppc-dev, linux-ide
In-Reply-To: <20071127153908.GB14183@localhost.localdomain>
[-- Attachment #1: Type: text/plain, Size: 599 bytes --]
On Tue, 27 Nov 2007 18:39:08 +0300 Anton Vorontsov <avorontsov@ru.mvista.com> wrote:
>
> +static int __devinit pata_of_platform_probe(struct of_device *ofdev,
> + const struct of_device_id *match)
> +{
> + uint32_t *prop;
Make this "const uint32_t *prop" or (more kernel like) "const u32 *prop" ...
> + prop = (uint32_t *)of_get_property(dn, "ioport-shift", NULL);
then you don't need this cast. Anytime you use a cast to get rid of
"const", is probably a mistake.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* RE: Xilinx devicetrees
From: Stephen Neuendorffer @ 2007-11-28 0:28 UTC (permalink / raw)
To: John Williams; +Cc: Michal Simek, linuxppc-embedded
In-Reply-To: <474CAE70.3030005@itee.uq.edu.au>
=20
> -----Original Message-----
> From: John Williams [mailto:jwilliams@itee.uq.edu.au]=20
> Sent: Tuesday, November 27, 2007 3:55 PM
> To: Stephen Neuendorffer
> Cc: David H. Lynch Jr.; linuxppc-embedded; Michal Simek
> Subject: Re: Xilinx devicetrees
>=20
>=20
> MicroBlaze is a highly configurable CPU in terms of its=20
> instruction set,=20
> features and so on. To make use of this, it is essential that each=20
> kernel image be compiled to match the CPU configuration. While a=20
> generic kernel, making use of no features (MUL, DIV, Shift,=20
> MSR ops etc)=20
> would run on any CPU, performance would be abysmal.
I think the userspace is actually much more critical than the kernel for
most of these things (with the exception of msrset/msrclr, and the
barrel shifter perhaps). Unfortunately, even if you implement an
alternatives-style mechanism for the kernel, you're still hosed for
userspace. Once I a big enough system, it's just unfeasible to
recompile everything anyway. I think this is where autoconfig starts to
break down.
> In my view it's not acceptable to present these as options=20
> for the user=20
> to select at kernel config time. With N yes/no parameters, there is 1=20
> correct configuration, and 2^N-1 incorrect ones. The odds of=20
> the user=20
> falling upon a configuration that at worst fails to boot, or=20
> at best is=20
> not optimally matched to the hardware, are high.
Yes. Autoconfig does handle this in a fairly nice way.
> This same issue also applies to C libraries and apps - they must be=20
> compiled with prior knowledge of the CPU. This is why our=20
> microblaze-uclinux-gcc toolchain, with multilib'd uClibc, is=20
> almost 400meg!
>=20
> Wrapping every mul, div, shift etc in a function call is clearly not=20
> feasible. Things like the msrset/msrclr ops have a modest but=20
> measurable impact on kernel code size and performance - it's just not=20
> reasonable to add any level of indirection in there.
>=20
> I have thought about dynamic (boot-time) code re-writing as one=20
> possibility here, but it very quickly gets nasty. All of the=20
> "optimised" opcodes (MUL/DIV/Shift etc) are smaller than=20
> their emulated=20
> counterparts, so in principle we could re-write the text segment with=20
> the optimised opcode, then NOP pad, but that's still inefficient. As=20
> soon as we start talking about dynamic code relocation, re-writing=20
> relative offsets in loops, ... yuck.. We'd be putting half of mb-ld=20
> into the arch early boot code (or bootloader...)
>=20
> The opposite approach, to build with all instructions enabled and=20
> install exception handlers to deal with the fixups, is also=20
> pretty awful.
It's not nice, I agree. I think the key principle should be that I
should be able to get a system working as quickly as possible, and I
might optimize things later. One thing that device trees will allow is
for *all* the drivers to get compiled in to the kernel, and only as a
late stage operation does a designer need to start throwing things away.
Using traps I can easily start with a 'kitchen sink' design, and start
discarding processor features, relying on the traps. When I get low
enough down on the performance curve, I can uas an autoconfig-type
mechanism to regain a little of what I lost by optimizing away the trap
overhead.=20
Personally, I think the easiest way out of all this is to just have less
configurability. For microblaze in general, this is too much of a
restriction, but microblaze used as a control processor running linux,
there are probably just a few design points that really make sense
(probably size optimized: no options except maybe msrset/msrclr, and the
kitchen sink). If we go that far, we don't really need people to ever
run autoconfig, or kernels, or anything. Especially considering there
is no easy way of selecting which of the 2^N design points I want
*anyway*. :)
> I find myself asking the question - for what use cases does=20
> the current=20
> static approach used in MicroBlaze (with the PetaLinux BSP /=20
> Kconfig.auto) *not* work?
>=20
> One compromise approach might be to have a script in=20
> arch/microblaze/scripts, called by the arch Makefile, that=20
> cracks open=20
> the DT at build time and extracts appropriate cpu flags.
Hmm... interesting idea, although parsing the source is likely
difficult... It's probably not worth it to go this far, I think. As
you say, why doesn't autoconfig of today work fine for this.
> Finally, what is the LKML position on DT files going into the kernel=20
> source tree?
Source .dts go in and get compiled to binary blobs at compile time. The
'big' recent controversy is whether the source->binary compiler dtc
should be mirrored in the Linux tree or not.
Steve
^ permalink raw reply
* Re: Xilinx devicetrees
From: Grant Likely @ 2007-11-28 0:27 UTC (permalink / raw)
To: John Williams; +Cc: Stephen Neuendorffer, Michal Simek, linuxppc-embedded
In-Reply-To: <474CAE70.3030005@itee.uq.edu.au>
On 11/27/07, John Williams <jwilliams@itee.uq.edu.au> wrote:
> Hi folks,
>
> Stephen Neuendorffer wrote:
>
> > > Binding it to a kernel, is a non-starter for us.
> >
> > I agree that this is not the best way of leveraging the power of device
> > trees. The point is that by using a device tree, you haven't lost
> > anything you can do currently. In the future we might have one kernel
> > which supports all versions of all our IP, along with all flavors of
> > microblaze and powerpc... You would only ever need to recompile this
> > kernel as a final optimization, if at all.
>
> I strongly support the OF / device tree work being done, from its own
> perspective and also as a path to MicroBlaze/PPC unification, however
> there is one critical difference that I have not seen adequately
> addressed yet.
>
> MicroBlaze is a highly configurable CPU in terms of its instruction set,
> features and so on. To make use of this, it is essential that each
> kernel image be compiled to match the CPU configuration. While a
> generic kernel, making use of no features (MUL, DIV, Shift, MSR ops etc)
> would run on any CPU, performance would be abysmal.
Looks like you've found the point of diminishing returns. :-) It is
probably not appropriate to try and encode CPU configuration into the
device tree *unless* it is only used to determine whether or not the
kernel as compiled will run on that CPU; but even by then you're
already running code on the platform. :-)
>
> In my view it's not acceptable to present these as options for the user
> to select at kernel config time. With N yes/no parameters, there is 1
> correct configuration, and 2^N-1 incorrect ones. The odds of the user
> falling upon a configuration that at worst fails to boot, or at best is
> not optimally matched to the hardware, are high.
>
> This same issue also applies to C libraries and apps - they must be
> compiled with prior knowledge of the CPU. This is why our
> microblaze-uclinux-gcc toolchain, with multilib'd uClibc, is almost 400meg!
>
> Wrapping every mul, div, shift etc in a function call is clearly not
> feasible. Things like the msrset/msrclr ops have a modest but
> measurable impact on kernel code size and performance - it's just not
> reasonable to add any level of indirection in there.
>
> I have thought about dynamic (boot-time) code re-writing as one
> possibility here, but it very quickly gets nasty. All of the
> "optimised" opcodes (MUL/DIV/Shift etc) are smaller than their emulated
> counterparts, so in principle we could re-write the text segment with
> the optimised opcode, then NOP pad, but that's still inefficient. As
> soon as we start talking about dynamic code relocation, re-writing
> relative offsets in loops, ... yuck.. We'd be putting half of mb-ld
> into the arch early boot code (or bootloader...)
>
> The opposite approach, to build with all instructions enabled and
> install exception handlers to deal with the fixups, is also pretty awful.
>
> I find myself asking the question - for what use cases does the current
> static approach used in MicroBlaze (with the PetaLinux BSP /
> Kconfig.auto) *not* work?
>
> One compromise approach might be to have a script in
> arch/microblaze/scripts, called by the arch Makefile, that cracks open
> the DT at build time and extracts appropriate cpu flags.
>
> Finally, what is the LKML position on DT files going into the kernel
> source tree?
arch/powerpc is awash with .dts files in the kernel tree. It's a
practice that is encouraged for most of the embedded boards. :-)
However, for something like xilinx virtex ppc and microblaze it
probably doesn't make much sense for anything other than the Xilinx
reference design bitstreams. (at least in mainline)
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: [PATCH] powerpc: fix os-term usage on kernel panic
From: Will Schmidt @ 2007-11-28 0:15 UTC (permalink / raw)
To: Linas Vepstas; +Cc: linuxppc-dev, paulus
In-Reply-To: <20071120012815.GB7969@austin.ibm.com>
(resending with the proper "from" addr this time).
I'm seeing some funky behavior on power5/power6 partitions with this
patch. A "/sbin/reboot" is now behaving much more like a
"/sbin/halt".
Anybody else seeing this, or is it time for me to call an exorcist for
my boxes?
-Will
On Mon, 2007-11-19 at 19:28 -0600, Linas Vepstas wrote:
> The rtas_os_term() routine was being called at the wrong time.
> The actual rtas call "os-term" will not ever return, and so
> calling it from the panic notifier is too early. Instead,
> call it from the machine_reset() call.
>
> The patch splits the rtas_os_term() routine into two: one
> part to capture the kernel panic message, invoked during
> the panic notifier, and another part that is invoked during
> machine_reset().
>
> Prior to this patch, the os-term call was never being made,
> because panic_timeout was always non-zero. Calling os-term
> helps keep the hypervisor happy! We have to keep the hypervisor
> happy to avoid service, dump and error reporting problems.
>
> Signed-off-by: Linas Vepstas <linas@austin.ibm.com>
>
> ----
> One could make a strong argument to move all of this code
> from kernel/rtas.c to platforms/pseries/setup.c I did not
> do this, just so as to make the changes minimal.
>
> arch/powerpc/kernel/rtas.c | 12 ++++++------
> arch/powerpc/platforms/pseries/setup.c | 3 ++-
> include/asm-powerpc/rtas.h | 3 ++-
> 3 files changed, 10 insertions(+), 8 deletions(-)
>
> Index: linux-2.6.24-rc2-git4/arch/powerpc/kernel/rtas.c
> ===================================================================
> --- linux-2.6.24-rc2-git4.orig/arch/powerpc/kernel/rtas.c 2007-11-19 18:58:53.000000000 -0600
> +++ linux-2.6.24-rc2-git4/arch/powerpc/kernel/rtas.c 2007-11-19 19:01:10.000000000 -0600
> @@ -631,18 +631,18 @@ void rtas_halt(void)
> /* Must be in the RMO region, so we place it here */
> static char rtas_os_term_buf[2048];
>
> -void rtas_os_term(char *str)
> +void rtas_panic_msg(char *str)
> {
> - int status;
> + snprintf(rtas_os_term_buf, 2048, "OS panic: %s", str);
> +}
>
> - if (panic_timeout)
> - return;
> +void rtas_os_term(void)
> +{
> + int status;
>
> if (RTAS_UNKNOWN_SERVICE == rtas_token("ibm,os-term"))
> return;
>
> - snprintf(rtas_os_term_buf, 2048, "OS panic: %s", str);
> -
> do {
> status = rtas_call(rtas_token("ibm,os-term"), 1, 1, NULL,
> __pa(rtas_os_term_buf));
> Index: linux-2.6.24-rc2-git4/arch/powerpc/platforms/pseries/setup.c
> ===================================================================
> --- linux-2.6.24-rc2-git4.orig/arch/powerpc/platforms/pseries/setup.c 2007-11-19 18:58:53.000000000 -0600
> +++ linux-2.6.24-rc2-git4/arch/powerpc/platforms/pseries/setup.c 2007-11-19 19:01:10.000000000 -0600
> @@ -507,7 +507,8 @@ define_machine(pseries) {
> .restart = rtas_restart,
> .power_off = pSeries_power_off,
> .halt = rtas_halt,
> - .panic = rtas_os_term,
> + .panic = rtas_panic_msg,
> + .machine_shutdown = rtas_os_term,
> .get_boot_time = rtas_get_boot_time,
> .get_rtc_time = rtas_get_rtc_time,
> .set_rtc_time = rtas_set_rtc_time,
> Index: linux-2.6.24-rc2-git4/include/asm-powerpc/rtas.h
> ===================================================================
> --- linux-2.6.24-rc2-git4.orig/include/asm-powerpc/rtas.h 2007-11-19 18:58:53.000000000 -0600
> +++ linux-2.6.24-rc2-git4/include/asm-powerpc/rtas.h 2007-11-19 19:01:10.000000000 -0600
> @@ -164,7 +164,8 @@ extern int rtas_call(int token, int, int
> extern void rtas_restart(char *cmd);
> extern void rtas_power_off(void);
> extern void rtas_halt(void);
> -extern void rtas_os_term(char *str);
> +extern void rtas_panic_msg(char *str);
> +extern void rtas_os_term(void);
> extern int rtas_get_sensor(int sensor, int index, int *state);
> extern int rtas_get_power_level(int powerdomain, int *level);
> extern int rtas_set_power_level(int powerdomain, int level, int *setlevel);
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
^ 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