* [PATCH] powerpc/85xx: Fix oops during MSI driver probe on MPC85xxMDS boards
From: Anton Vorontsov @ 2009-12-15 22:58 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
MPC85xx chips report the wrong value in feature reporting register,
and that causes the following oops:
Unable to handle kernel paging request for data at address 0x00000c00
Faulting instruction address: 0xc0019294
Oops: Kernel access of bad area, sig: 11 [#1]
MPC8569 MDS
Modules linked in:
[...]
NIP [c0019294] mpic_set_irq_type+0x2f0/0x368
LR [c0019124] mpic_set_irq_type+0x180/0x368
Call Trace:
[ef851d60] [c0019124] mpic_set_irq_type+0x180/0x368 (unreliable)
[ef851d90] [c007958c] __irq_set_trigger+0x44/0xd4
[ef851db0] [c007b550] set_irq_type+0x40/0x7c
[ef851dc0] [c0004a60] irq_create_of_mapping+0xb4/0x114
[ef851df0] [c0004af0] irq_of_parse_and_map+0x30/0x40
[ef851e20] [c0405678] fsl_of_msi_probe+0x1a0/0x328
[ef851e60] [c02e6438] of_platform_device_probe+0x5c/0x84
[...]
This is because mpic_alloc() assigns wrong values to
mpic->isu_{size,shift,mask}, and things eventually break when
_mpic_irq_read() is trying to use them.
This patch fixes the issue by enabling MPIC_BROKEN_FRR_NIRQS quirk.
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---
arch/powerpc/platforms/85xx/mpc85xx_mds.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/platforms/85xx/mpc85xx_mds.c b/arch/powerpc/platforms/85xx/mpc85xx_mds.c
index c5028a2..6491f7c 100644
--- a/arch/powerpc/platforms/85xx/mpc85xx_mds.c
+++ b/arch/powerpc/platforms/85xx/mpc85xx_mds.c
@@ -338,7 +338,8 @@ static void __init mpc85xx_mds_pic_init(void)
}
mpic = mpic_alloc(np, r.start,
- MPIC_PRIMARY | MPIC_WANTS_RESET | MPIC_BIG_ENDIAN,
+ MPIC_PRIMARY | MPIC_WANTS_RESET | MPIC_BIG_ENDIAN |
+ MPIC_BROKEN_FRR_NIRQS,
0, 256, " OpenPIC ");
BUG_ON(mpic == NULL);
of_node_put(np);
--
1.6.3.3
^ permalink raw reply related
* [POWERPC] add U-Boot bootcount driver.
From: Vitaly Bordug @ 2009-12-15 23:47 UTC (permalink / raw)
To: linuxppc-dev
From: Heiko Schocher <hs@denx.de>
This driver provides (read/write) access to the
U-Boot bootcounter via PROC FS or sysFS.
in u-boot, it uses a 8 byte mem area (it must hold the value over a
soft reset of course), for storing a bootcounter (it counts many soft
resets are done, on hard reset it starts with 0). If the bootcountvalue
exceeds the value in the env variable "bootlimit", and alternative
bootcmd stored in the env variable "altbootcmd" is run.
The bootcountregister gets configured via DTS.
for example on the mgsuvd board:
bootcount@0x3eb0 {
device_type = "bootcount";
compatible = "uboot,bootcount";
reg = <0x3eb0 0x08>;
};
This driver is tested on the mgcoge(82xx) and mgsuvd(8xx) board.
Signed-off-by: Heiko Schocher <hs@denx.de>
Signed-off-by: Wolfgang Denk <wd@denx.de>
Signed-off-by: Vitaly Bordyug <vitb@kernel.crashing.org>
---
I think there is no reason not to have this in mainline. Thoughts? And
I'm not sure what is right direction to push this - it's representation
of u-boot feature in fact, pretty useful tho.
arch/powerpc/boot/dts/mgcoge.dts | 6 +
arch/powerpc/boot/dts/mgsuvd.dts | 6 +
arch/powerpc/configs/mgsuvd_defconfig | 1
drivers/char/Kconfig | 6 +
drivers/char/Makefile | 1
drivers/char/bootcount.c | 222
+++++++++++++++++++++++++++++++++ 6 files changed, 242 insertions(+),
0 deletions(-) create mode 100644 drivers/char/bootcount.c
diff --git a/arch/powerpc/boot/dts/mgcoge.dts
b/arch/powerpc/boot/dts/mgcoge.dts index 0ce9664..7136fee 100644
--- a/arch/powerpc/boot/dts/mgcoge.dts
+++ b/arch/powerpc/boot/dts/mgcoge.dts
@@ -215,6 +215,12 @@
linux,network-index = <2>;
fsl,cpm-command = <0x16200300>;
};
+
+ bootcount@0x80f4 {
+ device_type = "bootcount";
+ compatible = "uboot,bootcount";
+ reg = <0x80f4 0x08>;
+ };
};
PIC: interrupt-controller@10c00 {
diff --git a/arch/powerpc/boot/dts/mgsuvd.dts
b/arch/powerpc/boot/dts/mgsuvd.dts index e4fc53a..59216a7 100644
--- a/arch/powerpc/boot/dts/mgsuvd.dts
+++ b/arch/powerpc/boot/dts/mgsuvd.dts
@@ -158,6 +158,12 @@
fsl,cpm-command = <0x80>;
fixed-link = <0 0 10 0 0>;
};
+
+ bootcount@0x3eb0 {
+ device_type = "bootcount";
+ compatible = "uboot,bootcount";
+ reg = <0x3eb0 0x08>;
+ };
};
};
};
diff --git a/arch/powerpc/configs/mgsuvd_defconfig
b/arch/powerpc/configs/mgsuvd_defconfig index 43c3c4f..298ced6 100644
--- a/arch/powerpc/configs/mgsuvd_defconfig
+++ b/arch/powerpc/configs/mgsuvd_defconfig
@@ -626,6 +626,7 @@ CONFIG_GEN_RTC=y
# CONFIG_GEN_RTC_X is not set
# CONFIG_R3964 is not set
# CONFIG_RAW_DRIVER is not set
+CONFIG_BOOTCOUNT=y
# CONFIG_TCG_TPM is not set
# CONFIG_I2C is not set
# CONFIG_SPI is not set
diff --git a/drivers/char/Kconfig b/drivers/char/Kconfig
index 6aad99e..5fe2d6c 100644
--- a/drivers/char/Kconfig
+++ b/drivers/char/Kconfig
@@ -1049,6 +1049,12 @@ config MAX_RAW_DEVS
Default is 256. Increase this number in case you need lots of
raw devices.
+config BOOTCOUNT
+ tristate "UBoot Bootcount driver"
+ depends on PPC
+ help
+ The UBoot Bootcount driver ...
+
config HPET
bool "HPET - High Precision Event Timer" if (X86 || IA64)
default n
diff --git a/drivers/char/Makefile b/drivers/char/Makefile
index 19a79dd..e3e2b1a 100644
--- a/drivers/char/Makefile
+++ b/drivers/char/Makefile
@@ -98,6 +98,7 @@ obj-$(CONFIG_NSC_GPIO) += nsc_gpio.o
obj-$(CONFIG_CS5535_GPIO) += cs5535_gpio.o
obj-$(CONFIG_GPIO_TB0219) += tb0219.o
obj-$(CONFIG_TELCLOCK) += tlclk.o
+obj-$(CONFIG_BOOTCOUNT) += bootcount.o
obj-$(CONFIG_MWAVE) += mwave/
obj-$(CONFIG_AGP) += agp/
diff --git a/drivers/char/bootcount.c b/drivers/char/bootcount.c
new file mode 100644
index 0000000..62fcabd
--- /dev/null
+++ b/drivers/char/bootcount.c
@@ -0,0 +1,222 @@
+/*
+ * This driver gives access(read/write) to the bootcounter used by
u-boot.
+ * Access is supported via procFS and sysFS.
+ *
+ * Copyright 2008 DENX Software Engineering GmbH
+ * Author: Heiko Schocher <hs@denx.de>
+ * Based on work from: Steffen Rumler (Steffen.Rumler@siemens.com)
+ *
+ * This program is free software; you can redistribute it and/or
modify it
+ * under the terms of the GNU General Public License as published
by the
+ * Free Software Foundation; either version 2 of the License, or (at
your
+ * option) any later version.
+ */
+
+#include <linux/mm.h>
+#include <linux/mman.h>
+#include <linux/init.h>
+#include <linux/capability.h>
+#include <linux/ptrace.h>
+#include <linux/device.h>
+
+#include <asm/uaccess.h>
+#include <asm/io.h>
+
+#include <linux/of_platform.h>
+
+#ifndef CONFIG_PROC_FS
+#error "PROC FS support must be switched-on"
+#endif
+
+
+#define UBOOT_BOOTCOUNT_MAGIC_OFFSET 0x04 /*
offset of magic number */ +#define
UBOOT_BOOTCOUNT_MAGIC 0xB001C041 /* magic number
value */ + +#define
UBOOT_BOOTCOUNT_PROC_ENTRY "driver/bootcount" /* PROC FS
entry under '/proc' */ + +/*
+ * This macro frees the machine specific function from bounds checking
and
+ * this like that...
+ */
+#define PRINT_PROC(fmt,args...) \
+ do { \
+ *len += sprintf( buffer+*len, fmt, ##args ); \
+ if (*begin + *len > offset + size) \
+ return( 0 ); \
+ if (*begin + *len < offset) { \
+ *begin += *len; \
+ *len = 0; \
+ } \
+ } while(0)
+
+void __iomem *mem = NULL;
+/*
+ * read U-Boot bootcounter
+ */
+static int
+read_bootcounter_info(char *buffer, int *len, off_t * begin, off_t
offset,
+ int size)
+{
+ unsigned long magic;
+ unsigned long counter;
+
+
+ magic = *((unsigned long *) (mem +
UBOOT_BOOTCOUNT_MAGIC_OFFSET));
+ counter = *((unsigned long *) (mem));
+
+ if (magic == UBOOT_BOOTCOUNT_MAGIC) {
+ PRINT_PROC ("%lu\n", counter);
+ } else {
+ PRINT_PROC ("bad magic: 0x%lu != 0x%lu\n", magic,
+ (unsigned long)UBOOT_BOOTCOUNT_MAGIC);
+ }
+
+ return 1;
+}
+
+/*
+ * read U-Boot bootcounter (wrapper)
+ */
+static int
+read_bootcounter(char *buffer, char **start, off_t offset, int size,
+ int *eof, void *arg)
+{
+ int len = 0;
+ off_t begin = 0;
+
+
+ *eof = read_bootcounter_info(buffer, &len, &begin, offset,
size); +
+ if (offset >= begin + len)
+ return 0;
+
+ *start = buffer + (offset - begin);
+ return size < begin + len - offset ? size : begin + len -
offset; +}
+
+/*
+ * write new value to U-Boot bootcounter
+ */
+static int
+write_bootcounter(struct file *file, const char *buffer, unsigned long
count,
+ void *data)
+{
+ unsigned long magic;
+ unsigned long *counter_ptr;
+
+
+ magic = *((unsigned long *) (mem +
UBOOT_BOOTCOUNT_MAGIC_OFFSET));
+ counter_ptr = (unsigned long *) (mem);
+
+ if (magic == UBOOT_BOOTCOUNT_MAGIC)
+ *counter_ptr = simple_strtol(buffer, NULL, 10);
+ else
+ return -EINVAL;
+
+ return count;
+}
+
+/* helper for the sysFS */
+static int show_str_bootcount(struct device *device,
+ struct device_attribute *attr,
+ char *buf)
+{
+ int ret = 0;
+ off_t begin = 0;
+
+ read_bootcounter_info(buf, &ret, &begin, 0, 20);
+ return ret;
+}
+static int store_str_bootcount(struct device *dev,
+ struct device_attribute *attr,
+ const char *buf,
+ size_t count)
+{
+ write_bootcounter(NULL, buf, count, NULL);
+ return count;
+}
+static DEVICE_ATTR(bootcount, S_IWUSR | S_IRUGO, show_str_bootcount,
store_str_bootcount); +
+static int __devinit bootcount_probe(struct of_device *ofdev,
+ const struct of_device_id
*match) +{
+ struct device_node *np = NULL;
+ struct proc_dir_entry *bootcount;
+
+ printk("%s (%d) %s: ", __FILE__, __LINE__, __FUNCTION__);
+ np = of_find_node_by_type(np, "bootcount");
+ if (!np) {
+ printk("%s no node, trying compatible node\n",
__FUNCTION__);
+ np = of_find_compatible_node(NULL, NULL,
"uboot,bootcount");
+ if (!np) {
+ printk("%s no node\n", __FUNCTION__);
+ return -ENODEV;
+ }
+ }
+ mem = of_iomap(np, 0);
+ if (mem == NULL) {
+ printk("%s couldnt map register.\n", __FUNCTION__);
+ }
+
+ /* init ProcFS */
+ if ((bootcount =
+ create_proc_entry(UBOOT_BOOTCOUNT_PROC_ENTRY, 0600,
+ NULL)) == NULL) {
+
+ printk(KERN_ERR "\n%s (%d): cannot create /proc/%s\n",
+ __FILE__, __LINE__,
UBOOT_BOOTCOUNT_PROC_ENTRY);
+ } else {
+
+ bootcount->read_proc = read_bootcounter;
+ bootcount->write_proc = write_bootcounter;
+ printk("created \"/proc/%s\"\n",
UBOOT_BOOTCOUNT_PROC_ENTRY);
+ }
+
+ if (device_create_file(&ofdev->dev, &dev_attr_bootcount))
+ printk("%s couldnt register sysFS entry.\n",
__FUNCTION__); +
+ return 0;
+}
+
+static int bootcount_remove(struct of_device *ofdev)
+{
+ BUG();
+ return 0;
+}
+
+static const struct of_device_id bootcount_match[] = {
+ {
+ .compatible = "uboot,bootcount",
+ },
+ {},
+};
+
+static struct of_platform_driver bootcount_driver = {
+ .driver = {
+ .name = "bootcount",
+ },
+ .match_table = bootcount_match,
+ .probe = bootcount_probe,
+ .remove = bootcount_remove,
+};
+
+
+static int __init uboot_bootcount_init(void)
+{
+ of_register_platform_driver(&bootcount_driver);
+ return 0;
+}
+
+static void __exit uboot_bootcount_cleanup(void)
+{
+ if (mem != NULL)
+ iounmap(mem);
+ remove_proc_entry(UBOOT_BOOTCOUNT_PROC_ENTRY, NULL);
+}
+
+module_init(uboot_bootcount_init);
+module_exit(uboot_bootcount_cleanup);
+
+MODULE_LICENSE ("GPL");
+MODULE_AUTHOR ("Steffen Rumler <steffen.rumler@siemens.com>");
+MODULE_DESCRIPTION ("Provide (read/write) access to the U-Boot
bootcounter via PROC FS");
^ permalink raw reply related
* Re: [POWERPC] add U-Boot bootcount driver.
From: David Gibson @ 2009-12-16 0:02 UTC (permalink / raw)
To: Vitaly Bordug; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <20091216024730.455b90fd@vitb-lp>
On Wed, Dec 16, 2009 at 02:47:30AM +0300, Vitaly Bordug wrote:
>
> From: Heiko Schocher <hs@denx.de>
>
> This driver provides (read/write) access to the
> U-Boot bootcounter via PROC FS or sysFS.
>
> in u-boot, it uses a 8 byte mem area (it must hold the value over a
> soft reset of course), for storing a bootcounter (it counts many soft
> resets are done, on hard reset it starts with 0). If the bootcountvalue
> exceeds the value in the env variable "bootlimit", and alternative
> bootcmd stored in the env variable "altbootcmd" is run.
>
> The bootcountregister gets configured via DTS.
> for example on the mgsuvd board:
>
> bootcount@0x3eb0 {
> device_type = "bootcount";
No device_type.
> compatible = "uboot,bootcount";
> reg = <0x3eb0 0x08>;
> };
This area should also be in the flattened tree's reserved map.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* [PATCH -tip tracing/kprobes] PPC: Powerpc port of the kprobe-based event tracer
From: Mahesh Salgaonkar @ 2009-12-16 4:39 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Masami Hiramatsu, Mahesh Salgaonkar
In-Reply-To: <20091216043619.963539987@mars.in.ibm.com>
This patch ports the kprobe-based event tracer to powerpc. This patch
is based in x86 port. This brings powerpc on par with x86.
Port the following API's to ppc for accessing registers and stack entries
from pt_regs.
- regs_query_register_offset(const char *name)
Query the offset of "name" register.
- regs_query_register_name(unsigned int offset)
Query the name of register by its offset.
- regs_get_register(struct pt_regs *regs, unsigned int offset)
Get the value of a register by its offset.
- regs_within_kernel_stack(struct pt_regs *regs, unsigned long addr)
Check the address is in the kernel stack.
- regs_get_kernel_stack_nth(struct pt_regs *reg, unsigned int nth)
Get Nth entry of the kernel stack. (N >= 0)
- regs_get_argument_nth(struct pt_regs *reg, unsigned int nth)
Get Nth argument at function call. (N >= 0)
Signed-off-by: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
Acked-by: Masami Hiramatsu <mhiramat@redhat.com>
---
arch/powerpc/include/asm/ptrace.h | 64 +++++++++++++++++
arch/powerpc/kernel/ptrace.c | 141 ++++++++++++++++++++++++++++++++++++++
kernel/trace/Kconfig | 2
3 files changed, 206 insertions(+), 1 deletion(-)
Index: linux-2.6-tip/arch/powerpc/include/asm/ptrace.h
===================================================================
--- linux-2.6-tip.orig/arch/powerpc/include/asm/ptrace.h
+++ linux-2.6-tip/arch/powerpc/include/asm/ptrace.h
@@ -83,6 +83,7 @@ struct pt_regs {
#define instruction_pointer(regs) ((regs)->nip)
#define user_stack_pointer(regs) ((regs)->gpr[1])
+#define kernel_stack_pointer(regs) ((regs)->gpr[1])
#define regs_return_value(regs) ((regs)->gpr[3])
#ifdef CONFIG_SMP
@@ -131,6 +132,69 @@ do { \
} while (0)
#endif /* __powerpc64__ */
+/* Query offset/name of register from its name/offset */
+#include <linux/stddef.h>
+#include <linux/thread_info.h>
+extern int regs_query_register_offset(const char *name);
+extern const char *regs_query_register_name(unsigned int offset);
+/* Get Nth argument at function call */
+extern unsigned long regs_get_argument_nth(struct pt_regs *regs,
+ unsigned int n);
+#define MAX_REG_OFFSET (offsetof(struct pt_regs, result))
+
+/**
+ * regs_get_register() - get register value from its offset
+ * @regs: pt_regs from which register value is gotten
+ * @offset: offset number of the register.
+ *
+ * regs_get_register returns the value of a register whose offset from @regs.
+ * The @offset is the offset of the register in struct pt_regs.
+ * If @offset is bigger than MAX_REG_OFFSET, this returns 0.
+ */
+static inline unsigned long regs_get_register(struct pt_regs *regs,
+ unsigned int offset)
+{
+ if (unlikely(offset > MAX_REG_OFFSET))
+ return 0;
+ return *(unsigned long *)((unsigned long)regs + offset);
+}
+
+/**
+ * regs_within_kernel_stack() - check the address in the stack
+ * @regs: pt_regs which contains kernel stack pointer.
+ * @addr: address which is checked.
+ *
+ * regs_within_kernel_stack() checks @addr is within the kernel stack page(s).
+ * If @addr is within the kernel stack, it returns true. If not, returns false.
+ */
+
+static inline bool regs_within_kernel_stack(struct pt_regs *regs,
+ unsigned long addr)
+{
+ return ((addr & ~(THREAD_SIZE - 1)) ==
+ (kernel_stack_pointer(regs) & ~(THREAD_SIZE - 1)));
+}
+
+/**
+ * regs_get_kernel_stack_nth() - get Nth entry of the stack
+ * @regs: pt_regs which contains kernel stack pointer.
+ * @n: stack entry number.
+ *
+ * regs_get_kernel_stack_nth() returns @n th entry of the kernel stack which
+ * is specified by @regs. If the @n th entry is NOT in the kernel stack,
+ * this returns 0.
+ */
+static inline unsigned long regs_get_kernel_stack_nth(struct pt_regs *regs,
+ unsigned int n)
+{
+ unsigned long *addr = (unsigned long *)kernel_stack_pointer(regs);
+ addr += n;
+ if (regs_within_kernel_stack(regs, (unsigned long)addr))
+ return *addr;
+ else
+ return 0;
+}
+
/*
* These are defined as per linux/ptrace.h, which see.
*/
Index: linux-2.6-tip/arch/powerpc/kernel/ptrace.c
===================================================================
--- linux-2.6-tip.orig/arch/powerpc/kernel/ptrace.c
+++ linux-2.6-tip/arch/powerpc/kernel/ptrace.c
@@ -39,6 +39,147 @@
#include <asm/system.h>
/*
+ * The parameter save area on the stack is used to store arguments being passed
+ * to callee function and is located at fixed offset from stack pointer.
+ */
+#ifdef CONFIG_PPC32
+#define PARAMETER_SAVE_AREA_OFFSET 24 /* bytes */
+#else /* CONFIG_PPC32 */
+#define PARAMETER_SAVE_AREA_OFFSET 48 /* bytes */
+#endif
+
+struct pt_regs_offset {
+ const char *name;
+ int offset;
+};
+
+#define REG_OFFSET_NAME(r) {.name = #r, .offset = offsetof(struct pt_regs, r)}
+#define REG_OFFSET_END {.name = NULL, .offset = 0}
+
+static const struct pt_regs_offset regoffset_table[] = {
+ REG_OFFSET_NAME(gpr[0]),
+ REG_OFFSET_NAME(gpr[1]),
+ REG_OFFSET_NAME(gpr[2]),
+ REG_OFFSET_NAME(gpr[3]),
+ REG_OFFSET_NAME(gpr[4]),
+ REG_OFFSET_NAME(gpr[5]),
+ REG_OFFSET_NAME(gpr[6]),
+ REG_OFFSET_NAME(gpr[7]),
+ REG_OFFSET_NAME(gpr[8]),
+ REG_OFFSET_NAME(gpr[9]),
+ REG_OFFSET_NAME(gpr[10]),
+ REG_OFFSET_NAME(gpr[11]),
+ REG_OFFSET_NAME(gpr[12]),
+ REG_OFFSET_NAME(gpr[13]),
+ REG_OFFSET_NAME(gpr[14]),
+ REG_OFFSET_NAME(gpr[15]),
+ REG_OFFSET_NAME(gpr[16]),
+ REG_OFFSET_NAME(gpr[17]),
+ REG_OFFSET_NAME(gpr[18]),
+ REG_OFFSET_NAME(gpr[19]),
+ REG_OFFSET_NAME(gpr[20]),
+ REG_OFFSET_NAME(gpr[21]),
+ REG_OFFSET_NAME(gpr[22]),
+ REG_OFFSET_NAME(gpr[23]),
+ REG_OFFSET_NAME(gpr[24]),
+ REG_OFFSET_NAME(gpr[25]),
+ REG_OFFSET_NAME(gpr[26]),
+ REG_OFFSET_NAME(gpr[27]),
+ REG_OFFSET_NAME(gpr[28]),
+ REG_OFFSET_NAME(gpr[29]),
+ REG_OFFSET_NAME(gpr[30]),
+ REG_OFFSET_NAME(gpr[31]),
+ REG_OFFSET_NAME(nip),
+ REG_OFFSET_NAME(msr),
+ REG_OFFSET_NAME(orig_gpr3),
+ REG_OFFSET_NAME(ctr),
+ REG_OFFSET_NAME(link),
+ REG_OFFSET_NAME(xer),
+ REG_OFFSET_NAME(ccr),
+#ifdef CONFIG_PPC64
+ REG_OFFSET_NAME(softe),
+#else
+ REG_OFFSET_NAME(mq),
+#endif
+ REG_OFFSET_NAME(trap),
+ REG_OFFSET_NAME(dar),
+ REG_OFFSET_NAME(dsisr),
+ REG_OFFSET_NAME(result),
+ REG_OFFSET_END,
+};
+
+/**
+ * regs_query_register_offset() - query register offset from its name
+ * @name: the name of a register
+ *
+ * regs_query_register_offset() returns the offset of a register in struct
+ * pt_regs from its name. If the name is invalid, this returns -EINVAL;
+ */
+int regs_query_register_offset(const char *name)
+{
+ const struct pt_regs_offset *roff;
+ for (roff = regoffset_table; roff->name != NULL; roff++)
+ if (!strcmp(roff->name, name))
+ return roff->offset;
+ return -EINVAL;
+}
+
+/**
+ * regs_query_register_name() - query register name from its offset
+ * @offset: the offset of a register in struct pt_regs.
+ *
+ * regs_query_register_name() returns the name of a register from its
+ * offset in struct pt_regs. If the @offset is invalid, this returns NULL;
+ */
+const char *regs_query_register_name(unsigned int offset)
+{
+ const struct pt_regs_offset *roff;
+ for (roff = regoffset_table; roff->name != NULL; roff++)
+ if (roff->offset == offset)
+ return roff->name;
+ return NULL;
+}
+
+static const int arg_offs_table[] = {
+ [0] = offsetof(struct pt_regs, gpr[3]),
+ [1] = offsetof(struct pt_regs, gpr[4]),
+ [2] = offsetof(struct pt_regs, gpr[5]),
+ [3] = offsetof(struct pt_regs, gpr[6]),
+ [4] = offsetof(struct pt_regs, gpr[7]),
+ [5] = offsetof(struct pt_regs, gpr[8]),
+ [6] = offsetof(struct pt_regs, gpr[9]),
+ [7] = offsetof(struct pt_regs, gpr[10])
+};
+
+/**
+ * regs_get_argument_nth() - get Nth argument at function call
+ * @regs: pt_regs which contains registers at function entry.
+ * @n: argument number.
+ *
+ * regs_get_argument_nth() returns @n th argument of a function call.
+ * Since usually the kernel stack will be changed right after function entry,
+ * you must use this at function entry. If the @n th entry is NOT in the
+ * kernel stack or pt_regs, this returns 0.
+ */
+unsigned long regs_get_argument_nth(struct pt_regs *regs, unsigned int n)
+{
+ if (n < ARRAY_SIZE(arg_offs_table))
+ return *(unsigned long *)((char *)regs + arg_offs_table[n]);
+ else {
+ /*
+ * If more arguments are passed that can be stored in
+ * registers, the remaining arguments are stored in the
+ * parameter save area located at fixed offset from stack
+ * pointer.
+ * Following the PowerPC ABI, the first few arguments are
+ * actually passed in registers (r3-r10), with equivalent space
+ * left unused in the parameter save area.
+ */
+ n += (PARAMETER_SAVE_AREA_OFFSET / sizeof(unsigned long));
+ return regs_get_kernel_stack_nth(regs, n);
+ }
+}
+/*
* does not yet catch signals sent when the child dies.
* in exit.c or in signal.c.
*/
Index: linux-2.6-tip/kernel/trace/Kconfig
===================================================================
--- linux-2.6-tip.orig/kernel/trace/Kconfig
+++ linux-2.6-tip/kernel/trace/Kconfig
@@ -464,7 +464,7 @@ config BLK_DEV_IO_TRACE
config KPROBE_EVENT
depends on KPROBES
- depends on X86
+ depends on X86 || PPC
bool "Enable kprobes-based dynamic events"
select TRACING
default y
^ permalink raw reply
* Re: [Next] CPU Hotplug test failures on powerpc
From: Sachin Sant @ 2009-12-16 5:38 UTC (permalink / raw)
To: Peter Zijlstra
Cc: Ingo Molnar, linux-next, linux-kernel, Linux/PPC Development
In-Reply-To: <1260889402.4165.434.camel@twins>
Peter Zijlstra wrote:
> Could you try the below?
>
No luck. Still the same issue. The mask values don't change.
Thanks
-Sachin
> ---
> init/main.c | 7 +------
> 1 files changed, 1 insertions(+), 6 deletions(-)
>
> diff --git a/init/main.c b/init/main.c
> index 4051d75..4be7de2 100644
> --- a/init/main.c
> +++ b/init/main.c
> @@ -369,12 +369,6 @@ static void __init smp_init(void)
> {
> unsigned int cpu;
>
> - /*
> - * Set up the current CPU as possible to migrate to.
> - * The other ones will be done by cpu_up/cpu_down()
> - */
> - set_cpu_active(smp_processor_id(), true);
> -
> /* FIXME: This should be done in userspace --RR */
> for_each_present_cpu(cpu) {
> if (num_online_cpus() >= setup_max_cpus)
> @@ -486,6 +480,7 @@ static void __init boot_cpu_init(void)
> int cpu = smp_processor_id();
> /* Mark the boot cpu "present", "online" etc for SMP and UP case */
> set_cpu_online(cpu, true);
> + set_cpu_active(cpu, true);
> set_cpu_present(cpu, true);
> set_cpu_possible(cpu, true);
> }
>
>
>
--
---------------------------------
Sachin Sant
IBM Linux Technology Center
India Systems and Technology Labs
Bangalore, India
---------------------------------
^ permalink raw reply
* Re: [Next] CPU Hotplug test failures on powerpc
From: Xiaotian Feng @ 2009-12-16 6:25 UTC (permalink / raw)
To: Sachin Sant
Cc: Peter Zijlstra, linux-kernel, Linux/PPC Development, linux-next,
Ingo Molnar
In-Reply-To: <4B2224C7.1020908@in.ibm.com>
On Fri, Dec 11, 2009 at 6:53 PM, Sachin Sant <sachinp@in.ibm.com> wrote:
> While executing cpu_hotplug(from autotest) tests against latest
> next on a power6 box, the machine locks up. A soft reset shows
> the following trace
>
> cpu 0x0: Vector: 100 (System Reset) at [c00000000c9333d0]
> =C2=A0 pc: c0000000003433d8: .find_next_bit+0x54/0xc4
> =C2=A0 lr: c000000000342f10: .cpumask_next_and+0x4c/0x94
> =C2=A0 sp: c00000000c933650
> =C2=A0msr: 8000000000089032
> =C2=A0current =3D 0xc00000000c173840
> =C2=A0paca =C2=A0 =C2=A0=3D 0xc000000000bc2600
> =C2=A0 pid =C2=A0 =3D 2602, comm =3D hotplug06.top.s
> enter ? for help
> [link register =C2=A0 ] c000000000342f10 .cpumask_next_and+0x4c/0x94
> [c00000000c933650] c0000000000e9f34 .cpuset_cpus_allowed_locked+0x38/0x74
> (unreliable)
> [c00000000c9336e0] c000000000090074 .move_task_off_dead_cpu+0xc4/0x1ac
> [c00000000c9337a0] c0000000005e4e5c .migration_call+0x304/0x830
> [c00000000c933880] c0000000005e0880 .notifier_call_chain+0x68/0xe0
> [c00000000c933920] c00000000012a92c ._cpu_down+0x210/0x34c
> [c00000000c933a90] c00000000012aad8 .cpu_down+0x70/0xa8
> [c00000000c933b20] c000000000525940 .store_online+0x54/0x894
> [c00000000c933bb0] c000000000463430 .sysdev_store+0x3c/0x50
> [c00000000c933c20] c0000000001f8320 .sysfs_write_file+0x124/0x18c
> [c00000000c933ce0] c00000000017edac .vfs_write+0xd4/0x1fc
> [c00000000c933d80] c00000000017efdc .SyS_write+0x58/0xa0
> [c00000000c933e30] c0000000000085b4 syscall_exit+0x0/0x40
> --- Exception: c01 (System Call) at 00000fff9fa8a8f8
> SP (fffe7aef200) is in userspace
> 0:mon> e
> cpu 0x0: Vector: 100 (System Reset) at [c00000000c9333d0]
> =C2=A0 pc: c0000000003433d8: .find_next_bit+0x54/0xc4
> =C2=A0 lr: c000000000342f10: .cpumask_next_and+0x4c/0x94
> =C2=A0 sp: c00000000c933650
> =C2=A0msr: 8000000000089032
> =C2=A0current =3D 0xc00000000c173840
> =C2=A0paca =C2=A0 =C2=A0=3D 0xc000000000bc2600
> =C2=A0 pid =C2=A0 =3D 2602, comm =3D hotplug06.top.s
>
Does this testcase hotplug cpu 0 off?
> Last few messages from the dmesg log shows
>
> 0:mon> <4>IRQ 17 affinity broken off cpu 0
> <4>IRQ 18 affinity broken off cpu 0
> <4>IRQ 19 affinity broken off cpu 0
> <4>IRQ 264 affinity broken off cpu 0
> <4>cpu 0 (hwid 0) Ready to die...
> <7>clockevent: decrementer mult[83126e97] shift[32] cpu[0]
> <4>Processor 0 found.
> <4>IRQ 17 affinity broken off cpu 1
> <4>IRQ 18 affinity broken off cpu 1
> <4>IRQ 19 affinity broken off cpu 1
> <4>IRQ 264 affinity broken off cpu 1
> <4>cpu 1 (hwid 1) Ready to die...
> <7>clockevent: decrementer mult[83126e97] shift[32] cpu[1]
> <4>Processor 1 found.
> <4>cpu 1 (hwid 1) Ready to die...
> <7>clockevent: decrementer mult[83126e97] shift[32] cpu[1]
> <4>Processor 1 found.
> <4>cpu 1 (hwid 1) Ready to die...
> <6>process 2423 (bash) no longer affine to cpu1
> <7>clockevent: decrementer mult[83126e97] shift[32] cpu[1]
> <4>Processor 1 found.
> <4>cpu 1 (hwid 1) Ready to die...
> <7>clockevent: decrementer mult[83126e97] shift[32] cpu[1]
> <4>Processor 1 found.
> <4>cpu 1 (hwid 1) Ready to die...
> <7>clockevent: decrementer mult[83126e97] shift[32] cpu[1]
> <4>Processor 1 found.
> <4>cpu 1 (hwid 1) Ready to die...
> <3>INFO: RCU detected CPU 0 stall (t=3D1000 jiffies)
> <3>INFO: RCU detected CPU 0 stall (t=3D4000 jiffies)
> 0:mon>
>
> After some debugging a possible suspect seems to be commit
> 6ad4c18.. : sched: Fix balance vs hotplug race
>
> If i revert this patch i am able to execute the tests on this
> power6 without any issues.
> But at the same time the above patch is required to solve the
> cpu hotplug related race on x86_64(as a side note this same
> x86_64 issue can be recreated against latest Linus git as well)
> that i reported here :
>
> http://marc.info/?l=3Dlinux-kernel&m=3D125802682922299&w=3D2
>
> I will try few more iterations with and without the above
> patch just to make sure i have the correct results.
>
> If someone has a suggestion let me know.
>
> Thanks
> -Sachin
>
>
> --
>
> ---------------------------------
> Sachin Sant
> IBM Linux Technology Center
> India Systems and Technology Labs
> Bangalore, India
> ---------------------------------
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" i=
n
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at =C2=A0http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at =C2=A0http://www.tux.org/lkml/
>
^ permalink raw reply
* Re: [Next] CPU Hotplug test failures on powerpc
From: Sachin Sant @ 2009-12-16 6:41 UTC (permalink / raw)
To: Xiaotian Feng
Cc: Peter Zijlstra, linux-kernel, Linux/PPC Development, linux-next,
Ingo Molnar
In-Reply-To: <7b6bb4a50912152225p4f5dde13re83c439407c16eaf@mail.gmail.com>
Xiaotian Feng wrote:
> Does this testcase hotplug cpu 0 off?
>
No, i don't think so. It skips cpu0 during online/offline
process.
thanks
-Sachin
--
---------------------------------
Sachin Sant
IBM Linux Technology Center
India Systems and Technology Labs
Bangalore, India
---------------------------------
^ permalink raw reply
* Re: [Next] CPU Hotplug test failures on powerpc
From: Xiaotian Feng @ 2009-12-16 6:45 UTC (permalink / raw)
To: Sachin Sant
Cc: Peter Zijlstra, linux-kernel, Linux/PPC Development, linux-next,
Ingo Molnar
In-Reply-To: <4B288131.2050306@in.ibm.com>
On Wed, Dec 16, 2009 at 2:41 PM, Sachin Sant <sachinp@in.ibm.com> wrote:
> Xiaotian Feng wrote:
>>
>> Does this testcase hotplug cpu 0 off?
>>
>
> No, i don't think so. It skips cpu0 during online/offline
> process.
Then how could this happen ? Looks like cpu 0 is offline ....
0:mon> <4>IRQ 17 affinity broken off cpu 0
<4>IRQ 18 affinity broken off cpu 0
<4>IRQ 19 affinity broken off cpu 0
<4>IRQ 264 affinity broken off cpu 0
<4>cpu 0 (hwid 0) Ready to die...
<7>clockevent: decrementer mult[83126e97] shift[32] cpu[0]
>
> thanks
> -Sachin
>
> --
>
> ---------------------------------
> Sachin Sant
> IBM Linux Technology Center
> India Systems and Technology Labs
> Bangalore, India
> ---------------------------------
>
>
^ permalink raw reply
* RE: Problem with mini-PCI-E slot on P2020RDB
From: Mahajan Vivek-B08308 @ 2009-12-16 6:49 UTC (permalink / raw)
To: Felix Radensky, linuxppc-dev, Aggrwal Poonam-B10812, Kumar Gala
In-Reply-To: <4B27FEE3.80001@embedded-sol.com>
> -----Original Message-----
> From:=20
> linuxppc-dev-bounces+vivek.mahajan=3Dfreescale.com@lists.ozlabs.
> org=20
> [mailto:linuxppc-dev-bounces+vivek.mahajan=3Dfreescale.com@lists
.ozlabs.org] On Behalf Of Felix Radensky
> Sent: Wednesday, December 16, 2009 2:56 AM
> To: linuxppc-dev@ozlabs.org; Aggrwal Poonam-B10812; Kumar Gala
> Subject: Problem with mini-PCI-E slot on P2020RDB
>=20
> Hi,
>=20
> I'm trying to use mini-PCI-E WLAN card on P2020RDB running=20
> 2.6.32, but so far without success.
> ath9k driver identifies the device, I can run ifconfig,=20
> iwconfig and hostapd on wlan0, but device is not getting any=20
> interrupts, so I suspect the interrupt configuration is=20
> wrong. Atheros ath9k driver reports:
>=20
> phy0: Atheros AR9280 MAC/BB Rev:2 AR5133 RF Rev:d0:=20
> mem=3D0xf1060000, irq=3D16
>=20
> The mapping for irq 16 is:
>=20
> irq: irq 1 on host /soc@ffe00000/pic@40000 mapped to virtual irq 16
>=20
> According to /proc/interrupts:
>=20
> CPU0
> 16: 0 OpenPIC Edge ath9k
>=20
> The same problem happens if Atheros card is plugged (with=20
> adapter) into regular PCI-E slot.
>=20
> It seems that p2020rdb device tree is missing=20
> interrupt-map-mask and interrupt-map properties in PCI-E nodes.
>=20
> I've tried running kernel from latest FSL BSP for this board=20
> (based on 2.6.32-rc3). The device tree has the=20
> interrupt-map-mask and interrupt-map properties, and=20
> interrupt mapping is different:
>=20
> irq: irq 0 on host /soc@ffe00000/pic@40000 mapped to virtual irq 16
>=20
> In /proc/interrups I see
> CPU0
> 16: 100001 OpenPIC Level ath9k
>=20
> However, when ath9k driver is loaded I get this:
>=20
> irq 16: nobody cared (try booting with the "irqpoll" option)=20
> Call Trace:
> [efbefa40] [c00074b0] show_stack+0x4c/0x16c (unreliable)=20
> [efbefa70] [c0073970] __report_bad_irq+0x38/0xd0 [efbefa90]=20
> [c0073bd4] note_interrupt+0x1cc/0x22c [efbefac0] [c00747d0]=20
> handle_fasteoi_irq+0xf4/0x128 [efbefae0] [c0004eb8]=20
> do_IRQ+0xc8/0xf4 [efbefb00] [c001081c]=20
> ret_from_except+0x0/0x18 [efbefbc0] [00000000] (null)=20
> [efbefc10] [c0004d24] do_softirq+0x60/0x64 [efbefc20]=20
> [c0044670] irq_exit+0x88/0xa8 [efbefc30] [c0004ebc]=20
> do_IRQ+0xcc/0xf4 [efbefc50] [c001081c]=20
> ret_from_except+0x0/0x18 [efbefd10] [c00730b4]=20
> __setup_irq+0x320/0x39c [efbefd30] [c0073214]=20
> request_threaded_irq+0xe4/0x148 [efbefd60] [f2244218]=20
> ath_pci_probe+0x1b0/0x3a4 [ath9k] [efbefda0] [c01c386c]=20
> local_pci_probe+0x24/0x34 [efbefdb0] [c01c3bc0]=20
> pci_device_probe+0x84/0xa8 [efbefde0] [c01e86b8]=20
> driver_probe_device+0xa8/0x1a8 [efbefe00] [c01e8874]=20
> __driver_attach+0xbc/0xc0 [efbefe20] [c01e7d88]=20
> bus_for_each_dev+0x70/0xac [efbefe50] [c01e84d8]=20
> driver_attach+0x24/0x34 [efbefe60] [c01e7504]=20
> bus_add_driver+0xb8/0x278 [efbefe90] [c01e8bec]=20
> driver_register+0x84/0x178 [efbefeb0] [c01c3e6c]=20
> __pci_register_driver+0x54/0xe4 [efbefed0] [f2244434]=20
> ath_pci_init+0x28/0x38 [ath9k] [efbefee0] [f215702c]=20
> ath9k_init+0x2c/0x100 [ath9k] [efbefef0] [c0001d34]=20
> do_one_initcall+0x3c/0x1e8 [efbeff20] [c006f9f0]=20
> sys_init_module+0xf8/0x220 [efbeff40] [c00101c4]=20
> ret_from_syscall+0x0/0x3c
> handlers:
> [<f223badc>] (ath_isr+0x0/0x1b4 [ath9k]) Disabling IRQ #16
Looks like INTA is not being routed to IRQ0 properly for this
PCIe ctlr. Try changing the interrupt-map prop for the ctlr=20
at 0xffe0a000 to the following, temporarily:-
interrupt-map =3D <
/* IDSEL 0x0 */
0000 0x0 0x0 0x1 &mpic 0x1 0x1
0000 0x0 0x0 0x2 &mpic 0x2 0x1
0000 0x0 0x0 0x3 &mpic 0x3 0x1
0000 0x0 0x0 0x4 &mpic 0x0 0x1
>;
>=20
> Atheros card plugged into regular PCI-E slot works OK in FSL BSP.
>=20
> Any help in resolving this is much appreciated.
>=20
> Thanks.
>=20
> Felix.
>=20
Thanks,
Vivek
^ permalink raw reply
* Re: [Next] CPU Hotplug test failures on powerpc
From: Sachin Sant @ 2009-12-16 6:54 UTC (permalink / raw)
To: Xiaotian Feng
Cc: Peter Zijlstra, linux-kernel, Linux/PPC Development, linux-next,
Ingo Molnar
In-Reply-To: <7b6bb4a50912152245v61a7f1ebgb41f4857134f3476@mail.gmail.com>
Xiaotian Feng wrote:
> On Wed, Dec 16, 2009 at 2:41 PM, Sachin Sant <sachinp@in.ibm.com> wrote:
>
>> Xiaotian Feng wrote:
>>
>>> Does this testcase hotplug cpu 0 off?
>>>
>>>
>> No, i don't think so. It skips cpu0 during online/offline
>> process.
>>
>
> Then how could this happen ? Looks like cpu 0 is offline ....
> 0:mon> <4>IRQ 17 affinity broken off cpu 0
> <4>IRQ 18 affinity broken off cpu 0
> <4>IRQ 19 affinity broken off cpu 0
> <4>IRQ 264 affinity broken off cpu 0
> <4>cpu 0 (hwid 0) Ready to die...
> <7>clockevent: decrementer mult[83126e97] shift[32] cpu[0]
>
Sorry i was looking at only one script. Looking more closely
at the test there are 6 different sub tests. The rest of the
tests do seem to hotplug CPU 0.
Thanks
-Sachin
--
---------------------------------
Sachin Sant
IBM Linux Technology Center
India Systems and Technology Labs
Bangalore, India
---------------------------------
^ permalink raw reply
* Re: [Next] CPU Hotplug test failures on powerpc
From: Xiaotian Feng @ 2009-12-16 6:56 UTC (permalink / raw)
To: Sachin Sant
Cc: Peter Zijlstra, linux-kernel, Linux/PPC Development, linux-next,
Ingo Molnar
In-Reply-To: <4B279370.5050800@in.ibm.com>
On Tue, Dec 15, 2009 at 9:47 PM, Sachin Sant <sachinp@in.ibm.com> wrote:
> Peter Zijlstra wrote:
>>>
>>> I added some debug statements within the above code. This is a 2 cpu
>>> machine.
>>>
>>> XMON dest_cpu =3D 1024 . dead_cpu =3D 1 . nr_cpu_ids =3D 2
>>> XMON dest_cpu =3D 1024 XMON dest_cpu =3D 1024 . dead_cpu =3D 1
>>> XMON dest_cpu =3D 1024 . dead_cpu =3D 1 . nr_cpu_ids =3D 2
>>> XMON dest_cpu =3D 1024 XMON dest_cpu =3D 1024 . dead_cpu =3D 1
>>> XMON dest_cpu =3D 1024 . dead_cpu =3D 1 . nr_cpu_ids =3D 2
>>> XMON dest_cpu =3D 1024 XMON dest_cpu =3D 1024 . dead_cpu =3D 1
>>>
>>> Seems to me that the control is stuck in an infinite loop and hence the
>>> machine appears to be in hung state. The dest_cpu value is always 1024
>>> and never changes, which result in an infinite loop.
>>>
>>> In working scenario the o/p is something on the following lines
>>>
>>> XMON dest_cpu =3D 1024 . dead_cpu =3D 1 . nr_cpu_ids =3D 2
>>> XMON dest_cpu =3D 0 XMON dest_cpu =3D 1024 . dead_cpu =3D 1 . nr_cpu_id=
s =3D 2
>>> XMON dest_cpu =3D 0 XMON dest_cpu =3D 1024 . dead_cpu =3D 1 . nr_cpu_id=
s =3D 2
>>> XMON dest_cpu =3D 0
>>> Let me know if i should try to record any specific value ?
>>>
>>
>> Could you possibly print the two masks themselves? cpumask_scnprintf()
>> and friend come in handy for this.
>>
>> The dest_cpu=3D1024 thing seem to suggest the intersection between
>> p->cpus_allowed and cpu_active_mask is empty for some reason, even
>> though we forcefully reset p->cpus_allowed to the full set using
>> cpuset_cpus_allowed_locked().
>>
>
> So here is the data related to the two masks.
>
> cpu_active_mask =3D 00000000,00000000,00000000,00000000,00000000,00000000=
,
> 00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,
> 00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,
> 00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,
> 00000000,00000000
> XMON dest_cpu =3D 1024
>
How about cpu_online_mask? commit 6ad4c1 switches from cpu_online_mask
to cpu_active_mask.
Is there a mismatch for cpu_online_mask and cpu_active_mask?
> while p->cpus_allowed =3D =C2=A000000000,00000000,00000000,00000000,00000=
000,
> 00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,
> 00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,
> 00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,
> 00000000,00000000,00000001
> XMON dest_cpu =3D 1024
>
> In working scenario the above data looks like
>
> cpu_active_mask =3D 00000000,00000000,00000000,00000000,00000000,00000000=
,
> 00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,
> 00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,
> 00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,
> 00000000,00000002
> XMON dest_cpu =3D 1
>
> while p->cpus_allowed =3D =C2=A000000000,00000000,00000000,00000000,00000=
000,
> 00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,
> 00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,
> 00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,
> 00000000,00000000,00000002
> XMON dest_cpu =3D 1
>
>
> hope i got the data correct.
>
> Thanks
> -Sachin
>
>
> --
>
> ---------------------------------
> Sachin Sant
> IBM Linux Technology Center
> India Systems and Technology Labs
> Bangalore, India
> ---------------------------------
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-next" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at =C2=A0http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: [Next] CPU Hotplug test failures on powerpc
From: Peter Zijlstra @ 2009-12-16 7:14 UTC (permalink / raw)
To: Sachin Sant; +Cc: Ingo Molnar, linux-next, linux-kernel, Linux/PPC Development
In-Reply-To: <4B287242.5070002@in.ibm.com>
On Wed, 2009-12-16 at 11:08 +0530, Sachin Sant wrote:
> Peter Zijlstra wrote:
> > Could you try the below?
> >
> No luck. Still the same issue. The mask values don't change.
Bugger, that patch did solve a similar problem for a patch I'm working
on.
Can you maybe add a print of the cpu_active_mask() in set_cpu_active()
using WARN() so we can see where it changes the mask, and why it things
its empty?
> > ---
> > init/main.c | 7 +------
> > 1 files changed, 1 insertions(+), 6 deletions(-)
> >
> > diff --git a/init/main.c b/init/main.c
> > index 4051d75..4be7de2 100644
> > --- a/init/main.c
> > +++ b/init/main.c
> > @@ -369,12 +369,6 @@ static void __init smp_init(void)
> > {
> > unsigned int cpu;
> >
> > - /*
> > - * Set up the current CPU as possible to migrate to.
> > - * The other ones will be done by cpu_up/cpu_down()
> > - */
> > - set_cpu_active(smp_processor_id(), true);
> > -
> > /* FIXME: This should be done in userspace --RR */
> > for_each_present_cpu(cpu) {
> > if (num_online_cpus() >= setup_max_cpus)
> > @@ -486,6 +480,7 @@ static void __init boot_cpu_init(void)
> > int cpu = smp_processor_id();
> > /* Mark the boot cpu "present", "online" etc for SMP and UP case */
> > set_cpu_online(cpu, true);
> > + set_cpu_active(cpu, true);
> > set_cpu_present(cpu, true);
> > set_cpu_possible(cpu, true);
> > }
> >
> >
> >
>
>
^ permalink raw reply
* Re: [Next] CPU Hotplug test failures on powerpc
From: Peter Zijlstra @ 2009-12-16 7:18 UTC (permalink / raw)
To: Sachin Sant
Cc: linux-kernel, Linux/PPC Development, linux-next, Xiaotian Feng,
Ingo Molnar
In-Reply-To: <4B288413.2070704@in.ibm.com>
On Wed, 2009-12-16 at 12:24 +0530, Sachin Sant wrote:
> Xiaotian Feng wrote:
> > On Wed, Dec 16, 2009 at 2:41 PM, Sachin Sant <sachinp@in.ibm.com> wrote:
> >
> >> Xiaotian Feng wrote:
> >>
> >>> Does this testcase hotplug cpu 0 off?
> >>>
> >>>
> >> No, i don't think so. It skips cpu0 during online/offline
> >> process.
> >>
> >
> > Then how could this happen ? Looks like cpu 0 is offline ....
> > 0:mon> <4>IRQ 17 affinity broken off cpu 0
> > <4>IRQ 18 affinity broken off cpu 0
> > <4>IRQ 19 affinity broken off cpu 0
> > <4>IRQ 264 affinity broken off cpu 0
> > <4>cpu 0 (hwid 0) Ready to die...
> > <7>clockevent: decrementer mult[83126e97] shift[32] cpu[0]
> >
> Sorry i was looking at only one script. Looking more closely
> at the test there are 6 different sub tests. The rest of the
> tests do seem to hotplug CPU 0.
Ooh, cute, so you can actually hotplug cpu 0.. no wonder that didn't get
exposed on x86.
Still, the only time cpu_active_mask should not be equal to
cpu_online_mask is when we're in the middle of a hotplug, we clear
active early and set it late, but its all done under the hotplug mutex,
so we can at most have 1 cpu differences with online mask.
Unless of course, I messed up, which appears to be rather likely given
these problems ;-)
^ permalink raw reply
* Re: [Next] CPU Hotplug test failures on powerpc
From: Xiaotian Feng @ 2009-12-16 7:57 UTC (permalink / raw)
To: Peter Zijlstra
Cc: linux-kernel, Linux/PPC Development, linux-next, Ingo Molnar
In-Reply-To: <1260947890.8023.1281.camel@laptop>
On Wed, Dec 16, 2009 at 3:18 PM, Peter Zijlstra <peterz@infradead.org> wrote:
> On Wed, 2009-12-16 at 12:24 +0530, Sachin Sant wrote:
>> Xiaotian Feng wrote:
>> > On Wed, Dec 16, 2009 at 2:41 PM, Sachin Sant <sachinp@in.ibm.com> wrote:
>> >
>> >> Xiaotian Feng wrote:
>> >>
>> >>> Does this testcase hotplug cpu 0 off?
>> >>>
>> >>>
>> >> No, i don't think so. It skips cpu0 during online/offline
>> >> process.
>> >>
>> >
>> > Then how could this happen ? Looks like cpu 0 is offline ....
>> > 0:mon> <4>IRQ 17 affinity broken off cpu 0
>> > <4>IRQ 18 affinity broken off cpu 0
>> > <4>IRQ 19 affinity broken off cpu 0
>> > <4>IRQ 264 affinity broken off cpu 0
>> > <4>cpu 0 (hwid 0) Ready to die...
>> > <7>clockevent: decrementer mult[83126e97] shift[32] cpu[0]
>> >
>> Sorry i was looking at only one script. Looking more closely
>> at the test there are 6 different sub tests. The rest of the
>> tests do seem to hotplug CPU 0.
>
> Ooh, cute, so you can actually hotplug cpu 0.. no wonder that didn't get
> exposed on x86.
>
> Still, the only time cpu_active_mask should not be equal to
> cpu_online_mask is when we're in the middle of a hotplug, we clear
> active early and set it late, but its all done under the hotplug mutex,
> so we can at most have 1 cpu differences with online mask.
>
Could follow be possible? We know there's cpu 0 and cpu 1,
offline cpu1 > done
offline cpu0 > false
consider this in cpu_down code,
int __ref cpu_down(unsigned int cpu)
{
<snip>
set_cpu_active(cpu, false); // here, we set cpu 0 to inactive
synchronize_sched();
err = _cpu_down(cpu, 0);
out:
<snip>
}
Then in _cpu_down code:
static int __ref _cpu_down(unsigned int cpu, int tasks_frozen)
{
<snip>
if (num_online_cpus() == 1) // if we're trying to
offline cpu0, num_online_cpus will be 1
return -EBUSY; // after return back
to cpu_down, we didn't change cpu 0 back to active
if (!cpu_online(cpu))
return -EINVAL;
if (!alloc_cpumask_var(&old_allowed, GFP_KERNEL))
return -ENOMEM;
<snip>
}
Then cpu 0 is not active, but online, then we try to offline cpu1, .......
This can not be exposed because x86 does not have
/sys/devices/system/cpu0/online.
I guess following patch fixes this bug.
---
diff --git a/kernel/cpu.c b/kernel/cpu.c
index 291ac58..21ddace 100644
--- a/kernel/cpu.c
+++ b/kernel/cpu.c
@@ -199,14 +199,18 @@ static int __ref _cpu_down(unsigned int cpu, int
tasks_frozen)
.hcpu = hcpu,
};
- if (num_online_cpus() == 1)
+ if (num_online_cpus() == 1) {
+ set_cpu_active(cpu, true);
return -EBUSY;
+ }
if (!cpu_online(cpu))
return -EINVAL;
- if (!alloc_cpumask_var(&old_allowed, GFP_KERNEL))
+ if (!alloc_cpumask_var(&old_allowed, GFP_KERNEL)) {
+ set_cpu_active(cpu, true);
return -ENOMEM;
+ }
cpu_hotplug_begin();
err = __raw_notifier_call_chain(&cpu_chain, CPU_DOWN_PREPARE | mod,
> Unless of course, I messed up, which appears to be rather likely given
> these problems ;-)
>
>
^ permalink raw reply related
* Re: [Next] CPU Hotplug test failures on powerpc
From: Sachin Sant @ 2009-12-16 8:24 UTC (permalink / raw)
To: Xiaotian Feng
Cc: Peter Zijlstra, linux-kernel, Linux/PPC Development, linux-next,
Ingo Molnar
In-Reply-To: <7b6bb4a50912152357m75aea5dfl6fe063d716517baf@mail.gmail.com>
Xiaotian Feng wrote:
> Could follow be possible? We know there's cpu 0 and cpu 1,
>
> offline cpu1 > done
> offline cpu0 > false
>
> consider this in cpu_down code,
>
>
> int __ref cpu_down(unsigned int cpu)
> {
> <snip>
> set_cpu_active(cpu, false); // here, we set cpu 0 to inactive
>
> synchronize_sched();
>
> err = _cpu_down(cpu, 0);
> out:
> <snip>
> }
>
> Then in _cpu_down code:
>
> static int __ref _cpu_down(unsigned int cpu, int tasks_frozen)
> {
> <snip>
> if (num_online_cpus() == 1) // if we're trying to
> offline cpu0, num_online_cpus will be 1
> return -EBUSY; // after return back
> to cpu_down, we didn't change cpu 0 back to active
>
> if (!cpu_online(cpu))
> return -EINVAL;
>
> if (!alloc_cpumask_var(&old_allowed, GFP_KERNEL))
> return -ENOMEM;
> <snip>
> }
>
> Then cpu 0 is not active, but online, then we try to offline cpu1, .......
> This can not be exposed because x86 does not have
> /sys/devices/system/cpu0/online.
> I guess following patch fixes this bug.
>
Just tested this one on the POWER box and the test passed.
I did not observe the hang.
Thanks
-Sachin
> ---
> diff --git a/kernel/cpu.c b/kernel/cpu.c
> index 291ac58..21ddace 100644
> --- a/kernel/cpu.c
> +++ b/kernel/cpu.c
> @@ -199,14 +199,18 @@ static int __ref _cpu_down(unsigned int cpu, int
> tasks_frozen)
> .hcpu = hcpu,
> };
>
> - if (num_online_cpus() == 1)
> + if (num_online_cpus() == 1) {
> + set_cpu_active(cpu, true);
> return -EBUSY;
> + }
>
> if (!cpu_online(cpu))
> return -EINVAL;
>
> - if (!alloc_cpumask_var(&old_allowed, GFP_KERNEL))
> + if (!alloc_cpumask_var(&old_allowed, GFP_KERNEL)) {
> + set_cpu_active(cpu, true);
> return -ENOMEM;
> + }
>
> cpu_hotplug_begin();
> err = __raw_notifier_call_chain(&cpu_chain, CPU_DOWN_PREPARE | mod,
>
>
>
>> Unless of course, I messed up, which appears to be rather likely given
>> these problems ;-)
>>
>>
>>
>
>
--
---------------------------------
Sachin Sant
IBM Linux Technology Center
India Systems and Technology Labs
Bangalore, India
---------------------------------
^ permalink raw reply
* Re: [Next] CPU Hotplug test failures on powerpc
From: Xiaotian Feng @ 2009-12-16 9:07 UTC (permalink / raw)
To: Sachin Sant
Cc: Peter Zijlstra, linux-kernel, Linux/PPC Development, linux-next,
Ingo Molnar
In-Reply-To: <4B289955.2010705@in.ibm.com>
On Wed, Dec 16, 2009 at 4:24 PM, Sachin Sant <sachinp@in.ibm.com> wrote:
> Xiaotian Feng wrote:
>>
>> Could follow be possible? =C2=A0We know there's cpu 0 and cpu 1,
>>
>> offline cpu1 > done
>> offline cpu0 > false
>>
>> consider this in cpu_down code,
>>
>>
>> int __ref cpu_down(unsigned int cpu)
>> {
>> <snip>
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0set_cpu_active(cpu, false); // here, we set c=
pu 0 to inactive
>>
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0synchronize_sched();
>>
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0err =3D _cpu_down(cpu, 0);
>> out:
>> <snip>
>> }
>>
>> Then in _cpu_down code:
>>
>> static int __ref _cpu_down(unsigned int cpu, int tasks_frozen)
>> {
>> <snip>
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0if (num_online_cpus() =3D=3D 1) =C2=A0 =C2=A0=
=C2=A0 =C2=A0// if we're trying to
>> offline cpu0, num_online_cpus will be 1
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0return -EBUSY; =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0// aft=
er return back
>> to cpu_down, we didn't change cpu 0 back to active
>>
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0if (!cpu_online(cpu))
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0return -EINVAL;
>>
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0if (!alloc_cpumask_var(&old_allowed, GFP_KERN=
EL))
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0return -ENOMEM;
>> <snip>
>> }
>>
>> Then cpu 0 is not active, but online, then we try to offline cpu1, .....=
..
>> This can not be exposed because x86 does not have
>> /sys/devices/system/cpu0/online.
>> I guess following patch fixes this bug.
>>
>
> Just tested this one on the POWER box and the test passed.
> I did not observe the hang.
Thanks for confirm, I will send formatted patch to upstream then:-)
>
> Thanks
> -Sachin
>
>> ---
>> diff --git a/kernel/cpu.c b/kernel/cpu.c
>> index 291ac58..21ddace 100644
>> --- a/kernel/cpu.c
>> +++ b/kernel/cpu.c
>> @@ -199,14 +199,18 @@ static int __ref _cpu_down(unsigned int cpu, int
>> tasks_frozen)
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0.hcpu =3D hcpu,
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0};
>>
>> - =C2=A0 =C2=A0 =C2=A0 if (num_online_cpus() =3D=3D 1)
>> + =C2=A0 =C2=A0 =C2=A0 if (num_online_cpus() =3D=3D 1) {
>> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 set_cpu_active(cpu, t=
rue);
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0return -EBUSY;
>> + =C2=A0 =C2=A0 =C2=A0 }
>>
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0if (!cpu_online(cpu))
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0return -EINVAL;
>>
>> - =C2=A0 =C2=A0 =C2=A0 if (!alloc_cpumask_var(&old_allowed, GFP_KERNEL))
>> + =C2=A0 =C2=A0 =C2=A0 if (!alloc_cpumask_var(&old_allowed, GFP_KERNEL))=
{
>> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 set_cpu_active(cpu, t=
rue);
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0return -ENOMEM;
>> + =C2=A0 =C2=A0 =C2=A0 }
>>
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0cpu_hotplug_begin();
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0err =3D __raw_notifier_call_chain(&cpu_chain,=
CPU_DOWN_PREPARE | mod,
>>
>>
>>
>>>
>>> Unless of course, I messed up, which appears to be rather likely given
>>> these problems ;-)
>>>
>>>
>>>
>>
>>
>
>
> --
>
> ---------------------------------
> Sachin Sant
> IBM Linux Technology Center
> India Systems and Technology Labs
> Bangalore, India
> ---------------------------------
>
>
^ permalink raw reply
* Re: Problem with mini-PCI-E slot on P2020RDB
From: Felix Radensky @ 2009-12-16 9:26 UTC (permalink / raw)
To: Mahajan Vivek-B08308; +Cc: linuxppc-dev, Aggrwal Poonam-B10812
In-Reply-To: <0949C49693EF1A47A54B0F0113CDB4A607674F@zin33exm23.fsl.freescale.net>
Hi,
Mahajan Vivek-B08308 wrote:
>
>> Hi,
>>
>> I'm trying to use mini-PCI-E WLAN card on P2020RDB running
>> 2.6.32, but so far without success.
>> ath9k driver identifies the device, I can run ifconfig,
>> iwconfig and hostapd on wlan0, but device is not getting any
>> interrupts, so I suspect the interrupt configuration is
>> wrong. Atheros ath9k driver reports:
>>
>> phy0: Atheros AR9280 MAC/BB Rev:2 AR5133 RF Rev:d0:
>> mem=0xf1060000, irq=16
>>
>> The mapping for irq 16 is:
>>
>> irq: irq 1 on host /soc@ffe00000/pic@40000 mapped to virtual irq 16
>>
>> According to /proc/interrupts:
>>
>> CPU0
>> 16: 0 OpenPIC Edge ath9k
>>
>> The same problem happens if Atheros card is plugged (with
>> adapter) into regular PCI-E slot.
>>
>> It seems that p2020rdb device tree is missing
>> interrupt-map-mask and interrupt-map properties in PCI-E nodes.
>>
>> I've tried running kernel from latest FSL BSP for this board
>> (based on 2.6.32-rc3). The device tree has the
>> interrupt-map-mask and interrupt-map properties, and
>> interrupt mapping is different:
>>
>> irq: irq 0 on host /soc@ffe00000/pic@40000 mapped to virtual irq 16
>>
>> In /proc/interrups I see
>> CPU0
>> 16: 100001 OpenPIC Level ath9k
>>
>> However, when ath9k driver is loaded I get this:
>>
>> irq 16: nobody cared (try booting with the "irqpoll" option)
>> Call Trace:
>> [efbefa40] [c00074b0] show_stack+0x4c/0x16c (unreliable)
>> [efbefa70] [c0073970] __report_bad_irq+0x38/0xd0 [efbefa90]
>> [c0073bd4] note_interrupt+0x1cc/0x22c [efbefac0] [c00747d0]
>> handle_fasteoi_irq+0xf4/0x128 [efbefae0] [c0004eb8]
>> do_IRQ+0xc8/0xf4 [efbefb00] [c001081c]
>> ret_from_except+0x0/0x18 [efbefbc0] [00000000] (null)
>> [efbefc10] [c0004d24] do_softirq+0x60/0x64 [efbefc20]
>> [c0044670] irq_exit+0x88/0xa8 [efbefc30] [c0004ebc]
>> do_IRQ+0xcc/0xf4 [efbefc50] [c001081c]
>> ret_from_except+0x0/0x18 [efbefd10] [c00730b4]
>> __setup_irq+0x320/0x39c [efbefd30] [c0073214]
>> request_threaded_irq+0xe4/0x148 [efbefd60] [f2244218]
>> ath_pci_probe+0x1b0/0x3a4 [ath9k] [efbefda0] [c01c386c]
>> local_pci_probe+0x24/0x34 [efbefdb0] [c01c3bc0]
>> pci_device_probe+0x84/0xa8 [efbefde0] [c01e86b8]
>> driver_probe_device+0xa8/0x1a8 [efbefe00] [c01e8874]
>> __driver_attach+0xbc/0xc0 [efbefe20] [c01e7d88]
>> bus_for_each_dev+0x70/0xac [efbefe50] [c01e84d8]
>> driver_attach+0x24/0x34 [efbefe60] [c01e7504]
>> bus_add_driver+0xb8/0x278 [efbefe90] [c01e8bec]
>> driver_register+0x84/0x178 [efbefeb0] [c01c3e6c]
>> __pci_register_driver+0x54/0xe4 [efbefed0] [f2244434]
>> ath_pci_init+0x28/0x38 [ath9k] [efbefee0] [f215702c]
>> ath9k_init+0x2c/0x100 [ath9k] [efbefef0] [c0001d34]
>> do_one_initcall+0x3c/0x1e8 [efbeff20] [c006f9f0]
>> sys_init_module+0xf8/0x220 [efbeff40] [c00101c4]
>> ret_from_syscall+0x0/0x3c
>> handlers:
>> [<f223badc>] (ath_isr+0x0/0x1b4 [ath9k]) Disabling IRQ #16
>>
>
> Looks like INTA is not being routed to IRQ0 properly for this
> PCIe ctlr. Try changing the interrupt-map prop for the ctlr
> at 0xffe0a000 to the following, temporarily:-
>
> interrupt-map = <
> /* IDSEL 0x0 */
> 0000 0x0 0x0 0x1 &mpic 0x1 0x1
> 0000 0x0 0x0 0x2 &mpic 0x2 0x1
> 0000 0x0 0x0 0x3 &mpic 0x3 0x1
> 0000 0x0 0x0 0x4 &mpic 0x0 0x1
>
Thanks for your help. With this change "nobody cared" message disappears,
but interrupts are not coming at all.
Is it a SoC problem or a board problem ?
Thanks.
Felix.
^ permalink raw reply
* RE: Problem with mini-PCI-E slot on P2020RDB
From: Mahajan Vivek-B08308 @ 2009-12-16 9:52 UTC (permalink / raw)
To: Felix Radensky; +Cc: linuxppc-dev, Aggrwal Poonam-B10812
In-Reply-To: <4B28A7C3.6040209@embedded-sol.com>
> From: Felix Radensky [mailto:felix@embedded-sol.com]=20
> Sent: Wednesday, December 16, 2009 2:56 PM
> To: Mahajan Vivek-B08308
> Cc: linuxppc-dev@ozlabs.org; Aggrwal Poonam-B10812; Kumar Gala
> Subject: Re: Problem with mini-PCI-E slot on P2020RDB
>=20
> Hi,
> >
> > Looks like INTA is not being routed to IRQ0 properly for this PCIe=20
> > ctlr. Try changing the interrupt-map prop for the ctlr at=20
> 0xffe0a000=20
> > to the following, temporarily:-
> >
> > interrupt-map =3D <
> > /* IDSEL 0x0 */
> > 0000 0x0 0x0 0x1 &mpic 0x1 0x1
> > 0000 0x0 0x0 0x2 &mpic 0x2 0x1
> > 0000 0x0 0x0 0x3 &mpic 0x3 0x1
> > 0000 0x0 0x0 0x4 &mpic 0x0 0x1
> > =20
>=20
> Thanks for your help. With this change "nobody cared" message=20
> disappears, but interrupts are not coming at all.
>=20
> Is it a SoC problem or a board problem ?
As per the p2020rm, PCIe legacy INTA is shared with IRQ0 for=20
this ctlr, which is the exactly the case with other SoC's=20
p2020ds, mpc8536ds, mpc8572ds. To me it seems like a board=20
issue and it needs to be followed up.
I plugged in ralink rt2860 pcie wirless card in the mini-pcie=20
slot of p2020rdb, which ran fine becaused it used MSI by default.
How hard is it to enable MSI in the atheros wireless driver.
>=20
> Thanks.
>=20
> Felix.
>=20
Thanks,
Vivek
^ permalink raw reply
* Porting EP852 based system from kernel 2.4.24 to 2.6.x
From: Cristiano Cortezia @ 2009-12-16 11:19 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 903 bytes --]
I work on a EP825 (MPC852T) based system running a 2.4.24 linux kernel
(which I didn't bring up in first place). Now I need to bring the board
alive over the latest kernel it may be possible to.
I've managed to cross-compile 2.26.32 kernel using most of the options I
could take from the existing 2.4.24 .config.
I could also download the generated uImage to the board using u-boot 1.0.2.
Uncompressed OK and then hung.
I've checked on mailing lists that the 2.6 series works with dts
(device-tree-sources). There are built-in make targets to generate images
backward compatibles with ancient u-boot versions. Then I tried one of these
targets to build a cuImage.xxx, but trying to boot from it also hangs. I
guess there is no make target that correspond to EP852.
Could someone point me some directions on what should I probably be missing
(from the very start of the "default porting procedure") ?
[-- Attachment #2: Type: text/html, Size: 1005 bytes --]
^ permalink raw reply
* Re: MPC5200B XLB Configuration Issues, FEC RFIFO Events, ATA Crashes
From: Roman Fietze @ 2009-12-16 11:37 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20091209145748.GB3112@pengutronix.de>
Hello Wolfram,
On Wednesday 09 December 2009 15:57:48 Wolfram Sang wrote:
> Do you have a way to measure performance penalties?
As I said, I do.
And here they are. They won't win a price for the most impartial
benchmarks ever seen, but thet'll be a good starting point to get a
feeling what stability might cost.
The board is using the MPC5200B on a board derived from the old
lite5200, but with the fixes for the MPC5200B. All tests are run using
an ST940813AM hard drive with an ext2 and an ext3 of 10GB each,
default mkfs options. The OS is Debian 4.0. The network connection is
between a fast Athlon XP2 6400 and the target, using 100MBit/s wiring
and a 100MBit/s switch.
The F always stands for fast settings, coherent cache, XLB features
like snooping, etc. turned on, XLB config 0x0000a006 or 0x0001a006
(makes no or no big difference).
The S always stands for slow settings, non coherent cache, XLB
features like snooping, etc. turned on, XLB config 0x80012006.
Bonnie++ V1.03:
------Sequential Output------ --Sequential Input- --Random-
-Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP
=46 ext2: 256M 2676 99 14759 47 5502 24 2792 98 16201 26 136.2 4
------Sequential Create------ --------Random Create--------
-Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP
64 85 99 84712 99 14517 100 86 99 114078 100 309 99
------Sequential Output------ --Sequential Input- --Random-
-Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP
S ext2: 256M 2647 99 14462 56 5468 29 2778 99 15856 32 134.2 4
------Sequential Create------ --------Random Create--------
-Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP
64 87 99 85872 100 15919 99 88 99 114094 99 317 99
------Sequential Output------ --Sequential Input- --Random-
-Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP
=46 ext3: 256M 2461 96 13327 73 5792 29 2798 98 16213 27 133.9 3
------Sequential Create------ --------Random Create--------
-Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP
64 2826 92 59290 99 3803 71 2778 90 114706 100 3872 74
------Sequential Output------ --Sequential Input- --Random-
-Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP
S ext3: 256M 2455 97 13340 85 5533 33 2759 98 15855 32 136.7 4
------Sequential Create------ --------Random Create--------
-Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP
64 2774 92 59474 100 3810 74 2726 91 113937 100 3905 77
Netcat tests to or from my MPC5200B target. All times are the netcat
time -p output real/user/sys and the network data rate in MB/s. The
source data itself is either a dd from /dev/zero with bs=3D10M
count=3D1024 or a file of equal size either on an ext2 or ext3
filesystem. The destination is either /dev/null or a file on an ext2
or ext3.
Server:/dev/zero -> Target:/dev/null
F: 1594/15.3/1031 6.8
S: 1864/8.8/921 5.8
Target:/dev/zero -> Server:/dev/null
F: 1396/35.8/1361 7.7
S: 1578/51.5/1526 6.8
Server:/dev/zero -> Target:ext2
F: 1799/37.0/1721 6.0
S: 2093/42.6/2009 5.1
Target:ext2 -> Server:/dev/null
F: 2423/31.3/1030 4.4
S: 2820/15.2/1186 3.8
Server:/dev/zero -> Target:ext3
F: 2110/33.4/1912.88 5.1
S: 2397/47.5/2208.63 4.5
Target:ext3 -> Server:/dev/null
F: 2407/17.9/1016 4.5
S: 2676/15.4/1160 4.0
I repeated one or the other test and got comparable results.
And please keep in mind, that adding some more or less high load on
the SCLPC/LPC the F system crashed either right away or at least once
every few hours, depending on what we did (TX/RX, FLASH/FPGA,
SCLPC+DMA/SCLPC/CPU, ...), and depending on the concurrent load on the
=46EC and ATA. If you only need one or the other peripheral with your
system you might get away with alls the XLB fetures turned on.
Additionally to that, I got wrong data reading from FLASH or the FPGA
using SCLPC+DMA in the first few bytes with the fast settings, when I
did not manually flush or invalidate the cache prior to the DMA
submission as dma_map_single would do it in non cache coherent setups.
Roman
=2D-=20
Roman Fietze Telemotive AG B=FCro M=FChlhausen
Breitwiesen 73347 M=FChlhausen
Tel.: +49(0)7335/18493-45 http://www.telemotive.de
^ permalink raw reply
* Re: Problem with mini-PCI-E slot on P2020RDB
From: Felix Radensky @ 2009-12-16 12:00 UTC (permalink / raw)
To: Mahajan Vivek-B08308; +Cc: linuxppc-dev, Aggrwal Poonam-B10812
In-Reply-To: <0949C49693EF1A47A54B0F0113CDB4A6076776@zin33exm23.fsl.freescale.net>
Mahajan Vivek-B08308 wrote:
>> From: Felix Radensky [mailto:felix@embedded-sol.com]
>> Sent: Wednesday, December 16, 2009 2:56 PM
>> To: Mahajan Vivek-B08308
>> Cc: linuxppc-dev@ozlabs.org; Aggrwal Poonam-B10812; Kumar Gala
>> Subject: Re: Problem with mini-PCI-E slot on P2020RDB
>>
>> Hi,
>>
>>> Looks like INTA is not being routed to IRQ0 properly for this PCIe
>>> ctlr. Try changing the interrupt-map prop for the ctlr at
>>>
>> 0xffe0a000
>>
>>> to the following, temporarily:-
>>>
>>> interrupt-map = <
>>> /* IDSEL 0x0 */
>>> 0000 0x0 0x0 0x1 &mpic 0x1 0x1
>>> 0000 0x0 0x0 0x2 &mpic 0x2 0x1
>>> 0000 0x0 0x0 0x3 &mpic 0x3 0x1
>>> 0000 0x0 0x0 0x4 &mpic 0x0 0x1
>>>
>>>
>> Thanks for your help. With this change "nobody cared" message
>> disappears, but interrupts are not coming at all.
>>
>> Is it a SoC problem or a board problem ?
>>
>
> As per the p2020rm, PCIe legacy INTA is shared with IRQ0 for
> this ctlr, which is the exactly the case with other SoC's
> p2020ds, mpc8536ds, mpc8572ds. To me it seems like a board
> issue and it needs to be followed up.
>
> I plugged in ralink rt2860 pcie wirless card in the mini-pcie
> slot of p2020rdb, which ran fine becaused it used MSI by default.
> How hard is it to enable MSI in the atheros wireless driver.
>
>
I've enabled MSI in ath9k driver, by simply adding pci_enable_msi() and
pci_disable_msi() at relevant places. The MSI interrupt is allocated.
irq: irq 0 on host /soc@ffe00000/msi@41600 mapped to virtual irq 18
phy0: Atheros AR9280 MAC/BB Rev:2 AR5133 RF Rev:d0: mem=0xf2160000, irq=18
cat /proc/interrupts
CPU0
18: 0 FSL-MSI Edge ath9k
lspci -v shows that MSI was enabled on device
But I don't get any interrupts. I've posted a question to ath9k list,
maybe folks there
will have some ideas.
Thanks.
Felix.
^ permalink raw reply
* RE: Problem with mini-PCI-E slot on P2020RDB
From: Mahajan Vivek-B08308 @ 2009-12-16 12:27 UTC (permalink / raw)
To: Felix Radensky; +Cc: linuxppc-dev, Aggrwal Poonam-B10812
In-Reply-To: <4B28CBC4.4010501@embedded-sol.com>
> From: Felix Radensky [mailto:felix@embedded-sol.com]=20
> Sent: Wednesday, December 16, 2009 5:30 PM
> > As per the p2020rm, PCIe legacy INTA is shared with IRQ0 for this=20
> > ctlr, which is the exactly the case with other SoC's p2020ds,=20
> > mpc8536ds, mpc8572ds. To me it seems like a board issue and=20
> it needs=20
> > to be followed up.
> >
> > I plugged in ralink rt2860 pcie wirless card in the=20
> mini-pcie slot of=20
> > p2020rdb, which ran fine becaused it used MSI by default.
> > How hard is it to enable MSI in the atheros wireless driver.
> >
> > =20
>=20
> I've enabled MSI in ath9k driver, by simply adding=20
> pci_enable_msi() and
> pci_disable_msi() at relevant places. The MSI interrupt is allocated.
>=20
> irq: irq 0 on host /soc@ffe00000/msi@41600 mapped to virtual irq 18
> phy0: Atheros AR9280 MAC/BB Rev:2 AR5133 RF Rev:d0:=20
> mem=3D0xf2160000, irq=3D18
>=20
> cat /proc/interrupts
> CPU0
> 18: 0 FSL-MSI Edge ath9k
>=20
> lspci -v shows that MSI was enabled on device
>=20
> But I don't get any interrupts. I've posted a question to=20
> ath9k list, maybe folks there will have some ideas.
I just noticed a MSI enable bit in drivers/net/wireless/ath/ath9k/reg.h=20
as under, may be we need to trun this on:-
reg.h:1013:#define AR_PCIE_MSI 0x4094
reg.h:1014:#define AR_PCIE_MSI_ENABLE 0x00000001
>=20
> Thanks.
>=20
> Felix.
>=20
Thanks,
Vivek
^ permalink raw reply
* [PATCH] pata_mpc52xx: optimizing code size by change of ATA timing data types
From: Roman Fietze @ 2009-12-16 13:29 UTC (permalink / raw)
To: linuxppc-dev
Hello Everybody,
A totally simple patch that reduces the text size as of the
ppc_6xx-size command of pata_mpc52xx by more than 10%, by reducing the
rodata size from 0x4a4 to 0x17e bytes. This is simply done by changing
the data types of the ATA timing constants.
If you are interested at all, and it's worth the trouble, here the
details:
ppc_6xx-size:
text data bss dec hex filename
old: 6532 1068 0 7600 1db0 pata_mpc52xx.o
new: 5718 1068 0 6786 1a82 pata_mpc52xx.o
The (assembler) code itself doesn't really change very much. I double
checked the final results inside mpc52xx_ata_apply_timings() and they
match.
BTW: Should I break lines at col 72 or 80?
=46rom: Roman Fietze <roman.fietze@telemotive.de>
Date: Wed, 16 Dec 2009 13:10:31 +0100
Subject: [PATCH] pata_mpc52xx: reduce code size by simple change of constan=
t data types
Signed-off-by: Roman Fietze <roman.fietze@telemotive.de>
=2D--
drivers/ata/pata_mpc52xx.c | 78 ++++++++++++++++++++++------------------=
=2D---
1 files changed, 39 insertions(+), 39 deletions(-)
diff --git a/drivers/ata/pata_mpc52xx.c b/drivers/ata/pata_mpc52xx.c
index 2bc2dbe..e4e5e82 100644
=2D-- a/drivers/ata/pata_mpc52xx.c
+++ b/drivers/ata/pata_mpc52xx.c
@@ -64,13 +64,13 @@ struct mpc52xx_ata_priv {
=20
=20
/* ATAPI-4 PIO specs (in ns) */
=2Dstatic const int ataspec_t0[5] =3D {600, 383, 240, 180, 120};
=2Dstatic const int ataspec_t1[5] =3D { 70, 50, 30, 30, 25};
=2Dstatic const int ataspec_t2_8[5] =3D {290, 290, 290, 80, 70};
=2Dstatic const int ataspec_t2_16[5] =3D {165, 125, 100, 80, 70};
=2Dstatic const int ataspec_t2i[5] =3D { 0, 0, 0, 70, 25};
=2Dstatic const int ataspec_t4[5] =3D { 30, 20, 15, 10, 10};
=2Dstatic const int ataspec_ta[5] =3D { 35, 35, 35, 35, 35};
+static const u16 ataspec_t0[5] =3D {600, 383, 240, 180, 120};
+static const u16 ataspec_t1[5] =3D { 70, 50, 30, 30, 25};
+static const u16 ataspec_t2_8[5] =3D {290, 290, 290, 80, 70};
+static const u16 ataspec_t2_16[5] =3D {165, 125, 100, 80, 70};
+static const u16 ataspec_t2i[5] =3D { 0, 0, 0, 70, 25};
+static const u16 ataspec_t4[5] =3D { 30, 20, 15, 10, 10};
+static const u16 ataspec_ta[5] =3D { 35, 35, 35, 35, 35};
=20
#define CALC_CLKCYC(c,v) ((((v)+(c)-1)/(c)))
=20
@@ -78,13 +78,13 @@ static const int ataspec_ta[5] =3D { 35, 35, 35, =
35, 35};
=20
/* ATAPI-4 MDMA specs (in clocks) */
struct mdmaspec {
=2D u32 t0M;
=2D u32 td;
=2D u32 th;
=2D u32 tj;
=2D u32 tkw;
=2D u32 tm;
=2D u32 tn;
+ u8 t0M;
+ u8 td;
+ u8 th;
+ u8 tj;
+ u8 tkw;
+ u8 tm;
+ u8 tn;
};
=20
static const struct mdmaspec mdmaspec66[3] =3D {
@@ -101,23 +101,23 @@ static const struct mdmaspec mdmaspec132[3] =3D {
=20
/* ATAPI-4 UDMA specs (in clocks) */
struct udmaspec {
=2D u32 tcyc;
=2D u32 t2cyc;
=2D u32 tds;
=2D u32 tdh;
=2D u32 tdvs;
=2D u32 tdvh;
=2D u32 tfs;
=2D u32 tli;
=2D u32 tmli;
=2D u32 taz;
=2D u32 tzah;
=2D u32 tenv;
=2D u32 tsr;
=2D u32 trfs;
=2D u32 trp;
=2D u32 tack;
=2D u32 tss;
+ u8 tcyc;
+ u8 t2cyc;
+ u8 tds;
+ u8 tdh;
+ u8 tdvs;
+ u8 tdvh;
+ u8 tfs;
+ u8 tli;
+ u8 tmli;
+ u8 taz;
+ u8 tzah;
+ u8 tenv;
+ u8 tsr;
+ u8 trfs;
+ u8 trp;
+ u8 tack;
+ u8 tss;
};
=20
static const struct udmaspec udmaspec66[6] =3D {
@@ -270,7 +270,7 @@ mpc52xx_ata_compute_pio_timings(struct mpc52xx_ata_priv=
*priv, int dev, int pio)
{
struct mpc52xx_ata_timings *timing =3D &priv->timings[dev];
unsigned int ipb_period =3D priv->ipb_period;
=2D unsigned int t0, t1, t2_8, t2_16, t2i, t4, ta;
+ u32 t0, t1, t2_8, t2_16, t2i, t4, ta;
=20
if ((pio < 0) || (pio > 4))
return -EINVAL;
@@ -299,8 +299,8 @@ mpc52xx_ata_compute_mdma_timings(struct mpc52xx_ata_pri=
v *priv, int dev,
if (speed < 0 || speed > 2)
return -EINVAL;
=20
=2D t->mdma1 =3D (s->t0M << 24) | (s->td << 16) | (s->tkw << 8) | (s->tm);
=2D t->mdma2 =3D (s->th << 24) | (s->tj << 16) | (s->tn << 8);
+ t->mdma1 =3D ((u32)s->t0M << 24) | ((u32)s->td << 16) | ((u32)s->tkw << 8=
) | s->tm;
+ t->mdma2 =3D ((u32)s->th << 24) | ((u32)s->tj << 16) | ((u32)s->tn << 8);
t->using_udma =3D 0;
=20
return 0;
@@ -316,11 +316,11 @@ mpc52xx_ata_compute_udma_timings(struct mpc52xx_ata_p=
riv *priv, int dev,
if (speed < 0 || speed > 2)
return -EINVAL;
=20
=2D t->udma1 =3D (s->t2cyc << 24) | (s->tcyc << 16) | (s->tds << 8) | s->td=
h;
=2D t->udma2 =3D (s->tdvs << 24) | (s->tdvh << 16) | (s->tfs << 8) | s->tli;
=2D t->udma3 =3D (s->tmli << 24) | (s->taz << 16) | (s->tenv << 8) | s->tsr;
=2D t->udma4 =3D (s->tss << 24) | (s->trfs << 16) | (s->trp << 8) | s->tack;
=2D t->udma5 =3D (s->tzah << 24);
+ t->udma1 =3D ((u32)s->t2cyc << 24) | ((u32)s->tcyc << 16) | ((u32)s->tds =
<< 8) | s->tdh;
+ t->udma2 =3D ((u32)s->tdvs << 24) | ((u32)s->tdvh << 16) | ((u32)s->tfs <=
< 8) | s->tli;
+ t->udma3 =3D ((u32)s->tmli << 24) | ((u32)s->taz << 16) | ((u32)s->tenv <=
< 8) | s->tsr;
+ t->udma4 =3D ((u32)s->tss << 24) | ((u32)s->trfs << 16) | ((u32)s->trp <<=
8) | s->tack;
+ t->udma5 =3D (u32)s->tzah << 24;
t->using_udma =3D 1;
=20
return 0;
=2D-=20
1.6.5.3
Roman
=2D-=20
Roman Fietze Telemotive AG B=FCro M=FChlhausen
Breitwiesen 73347 M=FChlhausen
Tel.: +49(0)7335/18493-45 http://www.telemotive.de
^ permalink raw reply
* [PATCH 1/5] powerpc/iseries: use DECLARE_COMPLETION_ONSTACK for non-constant completion
From: Yong Zhang @ 2009-12-16 14:35 UTC (permalink / raw)
To: linux-kernel; +Cc: Paul Mackerras, linuxppc-dev
In-Reply-To: <1260974161-6934-1-git-send-email-yong.zhang0@gmail.com>
The _ONSTACK variant should be used for on-stack completion,
otherwise it will break lockdep.
Signed-off-by: Yong Zhang <yong.zhang0@gmail.com>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: linuxppc-dev@ozlabs.org
---
arch/powerpc/platforms/iseries/viopath.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/platforms/iseries/viopath.c b/arch/powerpc/platforms/iseries/viopath.c
index 49ff4dc..5aea94f 100644
--- a/arch/powerpc/platforms/iseries/viopath.c
+++ b/arch/powerpc/platforms/iseries/viopath.c
@@ -116,7 +116,7 @@ static int proc_viopath_show(struct seq_file *m, void *v)
u16 vlanMap;
dma_addr_t handle;
HvLpEvent_Rc hvrc;
- DECLARE_COMPLETION(done);
+ DECLARE_COMPLETION_ONSTACK(done);
struct device_node *node;
const char *sysid;
--
1.6.3.3
^ permalink raw reply related
* [PATCH v2 1/2] fsldma: Delete DMA_INTERRUPT capability
From: Vishnu Suresh @ 2009-12-16 15:34 UTC (permalink / raw)
To: linuxppc-dev, linux-kernel, linux-raid, dan.j.williams
Cc: Vishnu Suresh, B04825, R58472
The DMA_INTERRUPT is a NULL transfer, triggering a
Programming Error. Though this Error is handled in
the driver with the fix given in "fsldma: Fix the DMA
halt when using DMA_INTERRUPT async_tx transfer."
<f79abb627f033c85a6088231f20c85bc4a9bd757>,
the RAID5 operation, which initiated the transaction
via Async_tx, hangs.
Hence, this patch removes the DMA_INTERRUPT capability
and the associated code from the driver.
Signed-off-by: Vishnu Suresh <Vishnu@freescale.com>
---
Changes with respect to v1
o. Rebased to linux-next as of 20091216
drivers/dma/fsldma.c | 31 -------------------------------
1 files changed, 0 insertions(+), 31 deletions(-)
diff --git a/drivers/dma/fsldma.c b/drivers/dma/fsldma.c
index 296f9e7..272097a 100644
--- a/drivers/dma/fsldma.c
+++ b/drivers/dma/fsldma.c
@@ -449,35 +449,6 @@ static void fsl_dma_free_chan_resources(struct dma_chan *chan)
fsl_chan->desc_pool = NULL;
}
-static struct dma_async_tx_descriptor *
-fsl_dma_prep_interrupt(struct dma_chan *chan, unsigned long flags)
-{
- struct fsl_dma_chan *fsl_chan;
- struct fsl_desc_sw *new;
-
- if (!chan)
- return NULL;
-
- fsl_chan = to_fsl_chan(chan);
-
- new = fsl_dma_alloc_descriptor(fsl_chan);
- if (!new) {
- dev_err(fsl_chan->dev, "No free memory for link descriptor\n");
- return NULL;
- }
-
- new->async_tx.cookie = -EBUSY;
- new->async_tx.flags = flags;
-
- /* Insert the link descriptor to the LD ring */
- list_add_tail(&new->node, &new->tx_list);
-
- /* Set End-of-link to the last link descriptor of new list*/
- set_ld_eol(fsl_chan, new);
-
- return &new->async_tx;
-}
-
static struct dma_async_tx_descriptor *fsl_dma_prep_memcpy(
struct dma_chan *chan, dma_addr_t dma_dest, dma_addr_t dma_src,
size_t len, unsigned long flags)
@@ -1200,11 +1171,9 @@ static int __devinit of_fsl_dma_probe(struct of_device *dev,
- fdev->reg.start + 1);
dma_cap_set(DMA_MEMCPY, fdev->common.cap_mask);
- dma_cap_set(DMA_INTERRUPT, fdev->common.cap_mask);
dma_cap_set(DMA_SLAVE, fdev->common.cap_mask);
fdev->common.device_alloc_chan_resources = fsl_dma_alloc_chan_resources;
fdev->common.device_free_chan_resources = fsl_dma_free_chan_resources;
- fdev->common.device_prep_dma_interrupt = fsl_dma_prep_interrupt;
fdev->common.device_prep_dma_memcpy = fsl_dma_prep_memcpy;
fdev->common.device_is_tx_complete = fsl_dma_is_complete;
fdev->common.device_issue_pending = fsl_dma_memcpy_issue_pending;
--
1.6.4.2
^ permalink raw reply related
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