* [PATCH 1/2]: pSeries: Enable cpuidle for pSeries.
From: Arun R Bharadwaj @ 2009-08-19 12:58 UTC (permalink / raw)
To: Joel Schopp, Benjamin Herrenschmidt, Shaohua Li,
Venkatesh Pallipadi, Adam Belay, Peter Zijlstra, Ingo Molnar,
Vaidyanathan Srinivasan, Dipankar Sarma, Balbir Singh,
Gautham R Shenoy, Arun Bharadwaj
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <20090819125716.GA20627@linux.vnet.ibm.com>
* Arun R Bharadwaj <arun@linux.vnet.ibm.com> [2009-08-19 18:27:16]:
This patch enables the cpuidle option in Kconfig for pSeries.
It also adds the routine cpu_idle_wait.
Signed-off-by: Arun R Bharadwaj <arun@linux.vnet.ibm.com>
---
arch/powerpc/Kconfig | 18 ++++++++++++++++++
arch/powerpc/include/asm/system.h | 2 ++
arch/powerpc/platforms/pseries/setup.c | 20 ++++++++++++++++++++
drivers/cpuidle/cpuidle.c | 1 +
4 files changed, 41 insertions(+)
Index: linux.trees.git/arch/powerpc/Kconfig
===================================================================
--- linux.trees.git.orig/arch/powerpc/Kconfig
+++ linux.trees.git/arch/powerpc/Kconfig
@@ -88,6 +88,9 @@ config ARCH_HAS_ILOG2_U64
bool
default y if 64BIT
+config ARCH_HAS_CPU_IDLE_WAIT
+ def_bool y
+
config GENERIC_HWEIGHT
bool
default y
@@ -243,6 +246,21 @@ source "kernel/Kconfig.freezer"
source "arch/powerpc/sysdev/Kconfig"
source "arch/powerpc/platforms/Kconfig"
+menu "Power management options"
+
+source "drivers/cpuidle/Kconfig"
+
+config TPMD
+ tristate "TPMD power management support"
+ depends on PPC_PSERIES && CPU_IDLE
+ default y
+ help
+ Thermal and Power Management Devices (TPMD). This hooks onto cpuidle
+ infrastructure to help in idle cpu power management. Currently this
+ is enabled only for pSeries.
+
+endmenu
+
menu "Kernel options"
config HIGHMEM
Index: linux.trees.git/drivers/cpuidle/cpuidle.c
===================================================================
--- linux.trees.git.orig/drivers/cpuidle/cpuidle.c
+++ linux.trees.git/drivers/cpuidle/cpuidle.c
@@ -17,6 +17,7 @@
#include <linux/cpuidle.h>
#include <linux/ktime.h>
#include <linux/hrtimer.h>
+#include <linux/pm.h>
#include "cpuidle.h"
Index: linux.trees.git/arch/powerpc/platforms/pseries/setup.c
===================================================================
--- linux.trees.git.orig/arch/powerpc/platforms/pseries/setup.c
+++ linux.trees.git/arch/powerpc/platforms/pseries/setup.c
@@ -278,6 +278,26 @@ static struct notifier_block pci_dn_reco
.notifier_call = pci_dn_reconfig_notifier,
};
+static void do_nothing(void *unused)
+{
+}
+
+/*
+ * cpu_idle_wait - Used to ensure that all the CPUs discard old value of
+ * pm_idle and update to new pm_idle value. Required while changing pm_idle
+ * handler on SMP systems.
+ *
+ * Caller must have changed pm_idle to the new value before the call. Old
+ * pm_idle value will not be used by any CPU after the return of this function.
+ */
+void cpu_idle_wait(void)
+{
+ smp_mb();
+ /* kick all the CPUs so that they exit out of pm_idle */
+ smp_call_function(do_nothing, NULL, 1);
+}
+EXPORT_SYMBOL_GPL(cpu_idle_wait);
+
static void __init pSeries_setup_arch(void)
{
/* Discover PIC type and setup ppc_md accordingly */
Index: linux.trees.git/arch/powerpc/include/asm/system.h
===================================================================
--- linux.trees.git.orig/arch/powerpc/include/asm/system.h
+++ linux.trees.git/arch/powerpc/include/asm/system.h
@@ -546,5 +546,7 @@ extern void account_system_vtime(struct
extern struct dentry *powerpc_debugfs_root;
+void cpu_idle_wait(void);
+
#endif /* __KERNEL__ */
#endif /* _ASM_POWERPC_SYSTEM_H */
^ permalink raw reply
* [PATCH 2/2]: pSeries: Implement Thermal & Power Management Devices(TPMD) idle module.
From: Arun R Bharadwaj @ 2009-08-19 12:59 UTC (permalink / raw)
To: Joel Schopp, Benjamin Herrenschmidt, Shaohua Li,
Venkatesh Pallipadi, Adam Belay, Peter Zijlstra, Ingo Molnar,
Vaidyanathan Srinivasan, Dipankar Sarma, Balbir Singh,
Gautham R Shenoy
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <20090819125716.GA20627@linux.vnet.ibm.com>
* Arun R Bharadwaj <arun@linux.vnet.ibm.com> [2009-08-19 18:27:16]:
This patch creates the Thermal & Power Management Devices module, tpmd_idle
which implements the cpuidle infrasture for pseries.
It implements a tpmd_idle_loop() which would be the main idle loop called
from cpu_idle(). It makes decision of entering either snooze or nap state
based on the decision taken by the cpuidle governor.
Signed-off-by: Arun R Bharadwaj <arun@linux.vnet.ibm.com>
---
arch/powerpc/platforms/pseries/Makefile | 1
arch/powerpc/platforms/pseries/tpmd.h | 10 +
arch/powerpc/platforms/pseries/tpmd_idle.c | 192 +++++++++++++++++++++++++++++
3 files changed, 203 insertions(+)
Index: linux.trees.git/arch/powerpc/platforms/pseries/tpmd_idle.c
===================================================================
--- /dev/null
+++ linux.trees.git/arch/powerpc/platforms/pseries/tpmd_idle.c
@@ -0,0 +1,192 @@
+
+/*
+ * tpmd_idle - idle state submodule to the tpmd driver
+ *
+ * Copyright (C) 2009 Arun R Bharadwaj <arun@linux.vnet.ibm.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.
+ *
+ * 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.
+ *
+ * ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ */
+
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/init.h>
+#include <linux/moduleparam.h>
+#include <linux/cpuidle.h>
+#include <linux/cpu.h>
+
+#include <asm/paca.h>
+#include <asm/machdep.h>
+
+#include "plpar_wrappers.h"
+#include "tpmd.h"
+
+MODULE_AUTHOR("Arun R Bharadwaj");
+MODULE_DESCRIPTION("TPMD Idle State Driver");
+MODULE_LICENSE("GPL");
+
+struct cpuidle_driver tpmd_idle_driver = {
+ .name = "tpmd_idle",
+ .owner = THIS_MODULE,
+};
+
+void (*pm_idle)(void);
+EXPORT_SYMBOL(pm_idle);
+
+static void (*old_idle_power_save)(void);
+
+DEFINE_PER_CPU(struct tpmd_processor_power, power);
+
+#define IDLE_STATE_COUNT 2
+
+static int tpmd_idle_init(struct tpmd_processor_power *power)
+{
+ return cpuidle_register_device(&power->dev);
+}
+
+void tpmd_idle_exit(struct tpmd_processor_power *power)
+{
+ cpuidle_unregister_device(&power->dev);
+}
+
+static void snooze(void)
+{
+ local_irq_enable();
+ set_thread_flag(TIF_POLLING_NRFLAG);
+ while (!need_resched()) {
+ HMT_low();
+ HMT_very_low();
+ }
+ clear_thread_flag(TIF_POLLING_NRFLAG);
+ local_irq_disable();
+ smp_mb();
+}
+
+static void nap(void)
+{
+ HMT_medium();
+ smp_mb();
+ cede_processor();
+}
+
+static int tpmd_idle_loop(struct cpuidle_device *dev, struct cpuidle_state *st)
+{
+ ktime_t t1, t2;
+ s64 diff;
+ int ret;
+
+ get_lppaca()->idle = 1;
+ get_lppaca()->donate_dedicated_cpu = 1;
+
+ t1 = ktime_get();
+
+ if (strcmp(st->desc, "idle") == 0)
+ snooze();
+ else
+ nap();
+
+ t2 = ktime_get();
+ diff = ktime_to_us(ktime_sub(t2, t1));
+ if (diff > INT_MAX)
+ diff = INT_MAX;
+
+ ret = (int) diff;
+
+ get_lppaca()->idle = 0;
+ get_lppaca()->donate_dedicated_cpu = 0;
+
+ return ret;
+}
+
+static int tpmd_setup_cpuidle(struct tpmd_processor_power *power)
+{
+ int i;
+ struct cpuidle_state *state;
+ struct cpuidle_device *dev = &power->dev;
+
+ dev->cpu = power->id;
+
+ dev->enabled = 0;
+ for (i = 0; i < IDLE_STATE_COUNT; i++) {
+ state = &dev->states[i];
+
+ snprintf(state->name, CPUIDLE_NAME_LEN, "TPM%d", i);
+
+ switch (i) {
+ case 0:
+ strncpy(state->desc, "idle", CPUIDLE_DESC_LEN);
+ state->exit_latency = 0;
+ state->target_residency = 0;
+ state->enter = tpmd_idle_loop;
+ break;
+
+ case 1:
+ strncpy(state->desc, "nap", CPUIDLE_DESC_LEN);
+ state->exit_latency = 1;
+ state->target_residency = 100;
+ state->enter = tpmd_idle_loop;
+ break;
+ }
+ }
+
+ power->dev.state_count = i;
+ return 0;
+}
+
+static int tpmd_processor_get_power_info(struct tpmd_processor_power *power,
+ int cpu)
+{
+ power->id = cpu;
+ power->count = 2;
+ return 0;
+}
+
+static int __init tpmd_processor_init(void)
+{
+ int cpu;
+ int result = cpuidle_register_driver(&tpmd_idle_driver);
+
+ if (result < 0)
+ return result;
+
+ printk(KERN_DEBUG "TPMD idle driver registered\n");
+
+ for_each_online_cpu(cpu) {
+ tpmd_processor_get_power_info(&per_cpu(power, cpu), cpu);
+ tpmd_setup_cpuidle(&per_cpu(power, cpu));
+ tpmd_idle_init(&per_cpu(power, cpu));
+ }
+
+ printk(KERN_DEBUG "Using cpuidle idle loop\n");
+ old_idle_power_save = ppc_md.power_save;
+ ppc_md.power_save = pm_idle;
+ return 0;
+}
+
+static void __exit tpmd_processor_exit(void)
+{
+ int cpu;
+
+ ppc_md.power_save = old_idle_power_save;
+ for_each_online_cpu(cpu)
+ tpmd_idle_exit(&per_cpu(power, cpu));
+ cpuidle_unregister_driver(&tpmd_idle_driver);
+ printk(KERN_DEBUG "TPMD idle driver removed\n");
+}
+
+module_init(tpmd_processor_init);
+module_exit(tpmd_processor_exit);
Index: linux.trees.git/arch/powerpc/platforms/pseries/tpmd.h
===================================================================
--- /dev/null
+++ linux.trees.git/arch/powerpc/platforms/pseries/tpmd.h
@@ -0,0 +1,10 @@
+#include <linux/kernel.h>
+#include <linux/cpuidle.h>
+
+struct tpmd_processor_power {
+ struct cpuidle_device dev;
+ int count;
+ int id;
+};
+
+extern struct cpuidle_driver tpmd_idle_driver;
Index: linux.trees.git/arch/powerpc/platforms/pseries/Makefile
===================================================================
--- linux.trees.git.orig/arch/powerpc/platforms/pseries/Makefile
+++ linux.trees.git/arch/powerpc/platforms/pseries/Makefile
@@ -26,3 +26,4 @@ obj-$(CONFIG_HCALL_STATS) += hvCall_inst
obj-$(CONFIG_PHYP_DUMP) += phyp_dump.o
obj-$(CONFIG_CMM) += cmm.o
obj-$(CONFIG_DTL) += dtl.o
+obj-$(CONFIG_TPMD) += tpmd_idle.o
^ permalink raw reply
* Linux booting problem on powerpc 440
From: Sumesh Kaana @ 2009-08-19 13:01 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 5237 bytes --]
Hi all,
I am trying to boot linux kernel (2.6.30) on a custom built board.I am using simple ppc platform and attached are my dts file and boot log..
I've 16Mb of RAM,UART and UIC with powerpc 440x5 processor.Kernel Image size is less than 1 mb.
i am not using any bootloaders such as U-boot
i have a small program on reset vector which will copy linux bin image from flash to 4mb (Link Address as per wrapper script), after that execution starts from link address.
the problem that i face is kernel crashes in different places while booting for different linux images, but always mentioned that
TASK = 'swapper'
Can anyone tell what would be the problem..?
Thanks,
Sumesh.
boot log is as below:---------------------zImage starting: loaded at 0x00400000 (sp: 0x004deeb0)Allocating 0x1dad84 bytes for kernel ...gunzipping (0x00000000 <- 0x0040c000:0x004dd3f1)...done 0x1c31cc bytes
Linux/PowerPC load: console=ttyS0 root=/dev/ramFinalizing device tree... flat tree at 0x4eb300Top of RAM: 0x1000000, Total RAM: 0x1000000
Zone PFN ranges: DMA 0x00000000 -> 0x00001000 Normal 0x00001000 -> 0x00001000Movable zone start PFN for each nodeearly_node_map[1] active PFN ranges 0: 0x00000000 -> 0x00001000MMU: Allocated 1088 bytes of context maps for 255 contextsBuilt 1 zonelists in Zone order, mobility grouping off. Total pages: 4064Kernel command line: console=ttyS0 root=/dev/ramNR_IRQS:512UIC0 (32 IRQ sources) at DCR 0x1c0BUG: recent printk recursion!Oops: Kernel access of bad area, sig: 11 [#1]PREEMPT PowerPC 44x PlatformModules linked in:NIP: c010c848 LR: c010c9f8 CTR: 00000000REGS: c01bfc10 TRAP: 0300 Not tainted (2.6.30)MSR: 00021000 <ME,CE> CR: 22004042 XER: 20000000DEAR: 00000000, ESR: 00800000TASK = c01a94b8[0] 'swapper' THREAD: c01be000GPR00: 0000005a c01bfcc0 c01a94b8 c01c5eb0 c016f3db 00000002 c01c5eb1 00000000 GPR08: 00000000 c016f3dc c016f3dc 00000000 42004048 00f08000 c015276c c0152850 GPR16: c015261c c01528dc c01bfe20 ffffffff c01b8628 c01c5e8c 00000004 00000000 GPR24: ffffffff c01be000 0000000a c01c628c c01bff68 00000000 c01c5eb2 c016f3db NIP [c010c848] vsnprintf+0x75c/0xeb0LR [c010c9f8] vsnprintf+0x90c/0xeb0Call Trace:[c01bfcc0] [c010c41c] vsnprintf+0x330/0xeb0 (unreliable)[c01bfeb0] [c010d100] vscnprintf+0x18/0x38[c01bfec0] [c002ff10] vprintk+0x8c/0x350[c01bff60] [c0030224] printk+0x50/0x60[c01bffa0] [c0193830] pidhash_init+0x5c/0xd4[c01bffc0] [c018c744] start_kernel+0x150/0x284[c01bfff0] [c0000200] skpinv+0x190/0x1ccInstruction dump:540a073e 5400e13e 7d3100ae 7d7150ae 99280000 99680001 39070001 40a2ffd4 2f860005 409effc0 38000000 57ab06b0 <98080000> 7fc3f378 7f64db78 38a1003c ---[ end trace 31fd0ba7d8756001 ]---Kernel panic - not syncing: Attempted to kill the idle task!Call Trace:[c01bfaf0] [c0005d5c] show_stack+0x4c/0x16c (unreliable)[c01bfb30] [c002f17c] panic+0xa0/0x168[c01bfb80] [c0032eb8] do_exit+0x61c/0x638[c01bfbc0] [c000b60c] kernel_bad_stack+0x0/0x4c[c01bfbf0] [c000f310] bad_page_fault+0x90/0xd8[c01bfc00] [c000e184] handle_page_fault+0x7c/0x80[c01bfcc0] [c010c41c] vsnprintf+0x330/0xeb0[c01bfeb0] [c010d100] vscnprintf+0x18/0x38[c01bfec0] [c002ff10] vprintk+0x8c/0x350[c01bff60] [c0030224] printk+0x50/0x60[c01bffa0] [c0193830] pidhash_init+0x5c/0xd4[c01bffc0] [c018c744] start_kernel+0x150/0x284[c01bfff0] [c0000200] skpinv+0x190/0x1ccRebooting in 180 seconds...
device tree file as bellow:
----------------------------
/dts-v1/;
/ { model = "XXX,xxxx"; compatible = "XXX,xxxx"; #address-cells = <1>; #size-cells = <1>; dcr-parent = <&SKYBEAM_PPC>; chosen { bootargs = "console=ttyS0 root=/dev/ram"; linux,stdout-path = "/plb/serial@02080000"; } ; aliases { serial0 = &STD_UART; } ; memory { device_type = "memory"; reg = < 0x0 0x01000000 >; } ; cpus { #address-cells = <1>; #size-cells = <0>; SKYBEAM_PPC: cpu@0 { device_type = "cpu"; #address-cells = <1>; #size-cells = <1>; reg = <0>; clock-frequency = <25000000>; compatible = "PowerPC,440", "ibm,ppc440"; d-cache-line-size = <0x20>; d-cache-size = <0x8000>; dcr-access-method = "native"; dcr-controller ; i-cache-line-size = <0x20>; i-cache-size = <0x8000>; model = "PowerPC,440"; timebase-frequency = <25000000>; } ; } ; UIC0: interrupt-controller0 { compatible = "ibm,uic-440ep","ibm,uic"; interrupt-controller; cell-index = <0>; dcr-reg = <0x1c0 0x009>; #address-cells = <0>; #size-cells = <0>; #interrupt-cells = <2>; }; PLB: plb { #address-cells = <1>; #size-cells = <1>; compatible = "simple-bus"; ranges ; STD_UART: serial@02080000 { device_type = "serial"; compatible = "ns16550"; reg = <0x02080000 0x00000008>; virtual-reg = <0x02080000>; clock-frequency = <125000000>; current-speed = <9600>; interrupt-parent = <&UIC0>; interrupts = <0x5 0x4>; } ; } ;} ;
_________________________________________________________________
View photos of singles in your area Click Here
http://a.ninemsn.com.au/b.aspx?URL=http%3A%2F%2Fdating%2Eninemsn%2Ecom%2Eau%2Fsearch%2Fsearch%2Easpx%3Fexec%3Dgo%26tp%3Dq%26gc%3D2%26tr%3D1%26lage%3D18%26uage%3D55%26cl%3D14%26sl%3D0%26dist%3D50%26po%3D1%26do%3D2%26trackingid%3D1046138%26r2s%3D1&_t=773166090&_r=Hotmail_Endtext&_m=EXT
[-- Attachment #2: Type: text/html, Size: 12544 bytes --]
^ permalink raw reply
* Re: [PATCH v2] qe_lib: Set gpio data before changing the direction to output
From: Michael Barkowski @ 2009-08-19 13:30 UTC (permalink / raw)
To: avorontsov; +Cc: linuxppc-dev, Timur Tabi
In-Reply-To: <20090818225607.GA29960@oksana.dev.rtsoft.ru>
Anton Vorontsov wrote:
> On Tue, Aug 18, 2009 at 05:33:00PM -0500, Timur Tabi wrote:
>> Anton Vorontsov wrote:
>>> On Tue, Aug 18, 2009 at 05:20:44PM -0400, Michael Barkowski wrote:
>>>> This avoids having a short glitch if the desired initial value is not
>>>> the same as what was previously in the data register.
>>>>
>>>> Signed-off-by: Michael Barkowski <michaelbarkowski@ruggedcom.com>
>>> Acked-by: Anton Vorontsov <avorontsov@ru.mvista.com>
>> I don't have the time to test this patch, so I abstain from acking. :-)
>> If Anton likes it, that's good enough for me.
>
> You made me doubt for a moment. :-) Thanks for the suspiciousness.
>
> What happens if a pin was previously configured as input? Does our
> write to the data register survive? For MPC8xxx GPIO controllers
> it does. And randomly taken QE spec says:
>
> A write to CPDAT is latched, and if the corresponding CPDIR
> bits have configured the port pin as an output, the latched
> value is driven onto the respective pin. However, if the
> corresponding CPDIR bits have configured the port pin as an
> input, the latched value is prevented from reaching the pin.
>
> I guess we're safe, but Michael, could you actually test it
> (if not already)?
>
I had tested it before with the pin initially configured as "disabled".
I have now also tested it with the pin initially configured as "input".
The value written to CPDAT seems to survive and is driven onto the pin
once CPDIR is changed to 1, just as noted in the spec.
Tested on 8360, by probing with a logic analyzer.
There are lots of users of this code. I understand if you'd like it to
stay open for testing by others.
--
Michael Barkowski
^ permalink raw reply
* Re: [PATCH v2] qe_lib: Set gpio data before changing the direction to output
From: Anton Vorontsov @ 2009-08-19 13:32 UTC (permalink / raw)
To: Michael Barkowski; +Cc: linuxppc-dev, Timur Tabi
In-Reply-To: <4A8BFE6C.9030604@ruggedcom.com>
On Wed, Aug 19, 2009 at 09:30:20AM -0400, Michael Barkowski wrote:
> Anton Vorontsov wrote:
> > On Tue, Aug 18, 2009 at 05:33:00PM -0500, Timur Tabi wrote:
> >> Anton Vorontsov wrote:
> >>> On Tue, Aug 18, 2009 at 05:20:44PM -0400, Michael Barkowski wrote:
> >>>> This avoids having a short glitch if the desired initial value is not
> >>>> the same as what was previously in the data register.
> >>>>
> >>>> Signed-off-by: Michael Barkowski <michaelbarkowski@ruggedcom.com>
> >>> Acked-by: Anton Vorontsov <avorontsov@ru.mvista.com>
> >> I don't have the time to test this patch, so I abstain from acking. :-)
> >> If Anton likes it, that's good enough for me.
> >
> > You made me doubt for a moment. :-) Thanks for the suspiciousness.
> >
> > What happens if a pin was previously configured as input? Does our
> > write to the data register survive? For MPC8xxx GPIO controllers
> > it does. And randomly taken QE spec says:
> >
> > A write to CPDAT is latched, and if the corresponding CPDIR
> > bits have configured the port pin as an output, the latched
> > value is driven onto the respective pin. However, if the
> > corresponding CPDIR bits have configured the port pin as an
> > input, the latched value is prevented from reaching the pin.
> >
> > I guess we're safe, but Michael, could you actually test it
> > (if not already)?
> >
>
> I had tested it before with the pin initially configured as "disabled".
>
> I have now also tested it with the pin initially configured as "input".
>
> The value written to CPDAT seems to survive and is driven onto the pin
> once CPDIR is changed to 1, just as noted in the spec.
>
> Tested on 8360, by probing with a logic analyzer.
Great, thanks a lot! I think the patch is perfect.
--
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2
^ permalink raw reply
* Re: powerpc-next rebased
From: Kumar Gala @ 2009-08-19 13:43 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev list
In-Reply-To: <1250667232.4810.20.camel@pasglop>
On Aug 19, 2009, at 2:33 AM, Benjamin Herrenschmidt wrote:
> Allright it's done, let's hope I didn't screw up :-)
You screwed it up... :)
The commits you pulled in from me you seem to have changed the author
of the commits which is NOT cool at all. Adding signed-off-by is
good, changing the committer is ok, but changing the author of the
commit is not. Please fix this ASAP.
Here's an example (in your tree):
http://git.kernel.org/?p=linux/kernel/git/benh/powerpc.git;a=commitdiff;h=87f1e94c949c28fdaa079d5115a8010c9a40569d
vs the commit in my tree:
http://git.kernel.org/?p=linux/kernel/git/galak/powerpc.git;a=commit;h=d920991f7e02788ba2b468b3023e5bbbc7a32f30
- k
^ permalink raw reply
* Re: powerpc-next rebased
From: Kumar Gala @ 2009-08-19 13:54 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev list
In-Reply-To: <2E8B90A3-A3FD-4EC8-9D41-1BA9E8B261AB@kernel.crashing.org>
On Aug 19, 2009, at 8:43 AM, Kumar Gala wrote:
>
> On Aug 19, 2009, at 2:33 AM, Benjamin Herrenschmidt wrote:
>
>> Allright it's done, let's hope I didn't screw up :-)
>
> You screwed it up... :)
>
> The commits you pulled in from me you seem to have changed the
> author of the commits which is NOT cool at all. Adding signed-off-
> by is good, changing the committer is ok, but changing the author of
> the commit is not. Please fix this ASAP.
>
> Here's an example (in your tree):
>
> http://git.kernel.org/?p=linux/kernel/git/benh/powerpc.git;a=commitdiff;h=87f1e94c949c28fdaa079d5115a8010c9a40569d
>
> vs the commit in my tree:
>
> http://git.kernel.org/?p=linux/kernel/git/galak/powerpc.git;a=commit;h=d920991f7e02788ba2b468b3023e5bbbc7a32f30
I'll leave my tree alone to allow you to try and fix this. It looks
like the stuff you pulled in from Josh's tree also has similar foobar.
- k
^ permalink raw reply
* OF modalias
From: Wolfgang Grandegger @ 2009-08-19 14:15 UTC (permalink / raw)
To: linuxppc-dev
Hello,
I'm confused by the modalias'es created by OF devices, e.g.:
# cat /sys/devices/f0000000.soc5200/f0000f00.spi/modalias
of:NspiT<NULL>Cfsl,mpc5200b-spiCfsl,mpc5200-spi
First of all, the string "<NULL>" looks like an error.
I could then dynamically load a driver module for the SPI using:
# modprobe `cat sys/devices/f0000000.soc5200/f0000f00.spi/modalias`
This does make sense for the SPI device, but there are OF devices which
cannot really be used by a module driver, e.g.:
# cat /sys/devices/f0000000.soc5200/f0000500.interrupt-controller/modalias
of:Ninterrupt-controllerT<NULL>Cfsl,mpc5200b-picCfsl,mpc5200-pic
The same for localbus, cdm, etc. Does it make sense for these
to create a modalias file?
Likely I have missed something. Thanks for clarification.
Wolfgang.
^ permalink raw reply
* [PATCH v2] powerpc: Fix __flush_icache_range on 44x
From: Josh Boyer @ 2009-08-19 14:27 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev
The ptrace POKETEXT interface allows a process to modify the text pages of
a child process being ptraced, usually to insert breakpoints via trap
instructions. The kernel eventually calls copy_to_user_page, which in turn
calls __flush_icache_range to invalidate the icache lines for the child
process.
However, this function does not work on 44x due to the icache being virtually
indexed. This was noticed by a breakpoint being triggered after it had been
cleared by ltrace on a 440EPx board. The convenient solution is to do a
flash invalidate of the icache in the __flush_icache_range function.
Signed-off-by: Josh Boyer <jwboyer@linux.vnet.ibm.com>
---
I tested this on powerpc-next this morning using the same testcase as before.
diff --git a/arch/powerpc/kernel/misc_32.S b/arch/powerpc/kernel/misc_32.S
index 15f28e0..da9c0c4 100644
--- a/arch/powerpc/kernel/misc_32.S
+++ b/arch/powerpc/kernel/misc_32.S
@@ -342,10 +342,17 @@ END_FTR_SECTION_IFSET(CPU_FTR_COHERENT_ICACHE)
addi r3,r3,L1_CACHE_BYTES
bdnz 1b
sync /* wait for dcbst's to get to ram */
+#ifndef CONFIG_44x
mtctr r4
2: icbi 0,r6
addi r6,r6,L1_CACHE_BYTES
bdnz 2b
+#else
+ /* Flash invalidate on 44x because we are passed kmapped addresses and
+ this doesn't work for userspace pages due to the virtually tagged
+ icache. Sigh. */
+ iccci 0, r0
+#endif
sync /* additional sync needed on g4 */
isync
blr
^ permalink raw reply related
* Re: powerpc-next rebased
From: Kumar Gala @ 2009-08-19 14:35 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev list
In-Reply-To: <5CBF10F7-8927-47AD-B4F8-1F07754207A8@kernel.crashing.org>
On Aug 19, 2009, at 8:54 AM, Kumar Gala wrote:
>
> On Aug 19, 2009, at 8:43 AM, Kumar Gala wrote:
>
>>
>> On Aug 19, 2009, at 2:33 AM, Benjamin Herrenschmidt wrote:
>>
>>> Allright it's done, let's hope I didn't screw up :-)
>>
>> You screwed it up... :)
>>
>> The commits you pulled in from me you seem to have changed the
>> author of the commits which is NOT cool at all. Adding signed-off-
>> by is good, changing the committer is ok, but changing the author
>> of the commit is not. Please fix this ASAP.
>>
>> Here's an example (in your tree):
>>
>> http://git.kernel.org/?p=linux/kernel/git/benh/powerpc.git;a=commitdiff;h=87f1e94c949c28fdaa079d5115a8010c9a40569d
>>
>> vs the commit in my tree:
>>
>> http://git.kernel.org/?p=linux/kernel/git/galak/powerpc.git;a=commit;h=d920991f7e02788ba2b468b3023e5bbbc7a32f30
>
> I'll leave my tree alone to allow you to try and fix this. It looks
> like the stuff you pulled in from Josh's tree also has similar foobar.
>
> - k
To be nice I published a 'fix-author' branch on my kernel.org tree
that should be identical to your tree up to:
commit b045513a1d657178868a1b1c5c2c56b7ef67766d
Author: Kumar Gala <galak@kernel.crashing.org>
Date: Tue Aug 18 15:21:40 2009 +0000
powerpc/mm: Fix assert_pte_locked to work properly on uniprocessor
Since the pte_lockptr is a spinlock it gets optimized away on
uniprocessor builds so using spin_is_locked is not correct. We
can use
assert_spin_locked instead and get the proper behavior between UP
and
SMP builds.
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
I doesn't have any Signed-off-by from you for the commits from Josh or
I. Otherwise the Author's have been fixed.
- k
^ permalink raw reply
* Re: Linux booting problem on powerpc 440
From: Josh Boyer @ 2009-08-19 17:35 UTC (permalink / raw)
To: Sumesh Kaana; +Cc: linuxppc-dev
In-Reply-To: <BLU124-W26979C48CA968E784AEA0CB4FE0@phx.gbl>
On Wed, Aug 19, 2009 at 01:01:16PM +0000, Sumesh Kaana wrote:
>
>
>
>Hi all,
>I am trying to boot linux kernel (2.6.30) on a custom built board.I am using simple ppc platform and attached are my dts file and boot log..
>I've 16Mb of RAM,UART and UIC with powerpc 440x5 processor.Kernel Image size is less than 1 mb.
>i am not using any bootloaders such as U-boot
>i have a small program on reset vector which will copy linux bin image from flash to 4mb (Link Address as per wrapper script), after that execution starts from link address.
How large of an initial TLB are you setting up for all of this in your simple
bootloader?
>the problem that i face is kernel crashes in different places while booting for different linux images, but always mentioned that
>TASK = 'swapper'
>
>Can anyone tell what would be the problem..?
I won't quote the file itself since your email is terribly word-wrapped, but
the #address-cells = <1> in the root node looks incorrect for a 440 based CPU.
It should be 2, as 440 does 36-bit addressing. Similarly for the PLB node.
You would need to fix the memory reg property for this.
The CPU node should probably have #size-cells = <0>, though I don't think that
matters much.
The serial port appears to be at an odd address for a 440 based SoC, but I
have no idea if that is correct or not.
Outside of those issues, I can't think of anything off the top of my head that
would cause the panic you are seeing.
josh
^ permalink raw reply
* Re: [PATCH] spinlock: __raw_spin_is_locked() should return true for UP
From: Scott Wood @ 2009-08-19 18:50 UTC (permalink / raw)
To: Linus Torvalds
Cc: peterz, linux-kernel, Steven Rostedt, linuxppc-dev, mingo, tglx
In-Reply-To: <alpine.LFD.2.01.0908181640120.3158@localhost.localdomain>
On Tue, Aug 18, 2009 at 04:52:20PM -0700, Linus Torvalds wrote:
>
>
> On Tue, 18 Aug 2009, Steven Rostedt wrote:
> >
> > > The thing is, some people may assert that a lock is held, but others could
> > > easily be looping until it's not held using something like
> > >
> > > while (spin_is_locked(lock))
> > > cpu_relax();
> >
> > Wouldn't something like that be really racey? And anyone doing such a
> > thing had better have that code within an #ifdef CONFIG_SMP.
>
> Sure, it's hopefully inside a #ifdef CONFIG_SMP.
>
> And no, it's not necessarily racy. Sure, it's race in itself if that's all
> you are doing, but I could imagine writing that kind of code if I knew
> some lock was likely held, and I wanted to avoid doing a "try_lock()"
> until it got released.
So you'd basically have the effect of a spin_lock(), except with the
bonus of breaking RT hacks that do something other than spin, and
preventing arch code from doing certain types of relaxation that are only
appropriate when waiting on a lock (such as mdors on powerpc, which
de-emphasizes until a reservation is broken).
Not exactly something we should encourage, IMHO.
-Scott
^ permalink raw reply
* Re: [PATCH/RFC] powerpc/mm: Cleanup handling of execute permission
From: Becky Bruce @ 2009-08-19 20:59 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev list, Kumar Gala
In-Reply-To: <1250634800.4810.1.camel@pasglop>
On Aug 18, 2009, at 5:33 PM, Benjamin Herrenschmidt wrote:
> On Tue, 2009-08-18 at 16:56 -0400, Josh Boyer wrote:
>> On Fri, Aug 14, 2009 at 05:39:42PM -0500, Becky Bruce wrote:
>>> Ben,
>>>
>>> This breaks the boot on 8572. I don't know why yet (and I'm
>>> probably
>>> not going to figure it out before I go home, because, frankly,
>>> it's late
>>> on a Friday afternoon and I need a glass of wine or, perhaps, a
>>> beer).
>>>
>>> Kumar and I will poke into this more and let you know what we find
>>> out -
>>> in the meantime, if you have any brilliant flashes, pony up!
>>
>> I tested this on a 440EPx NFS rootfs boot too. It doesn't cause
>> init itself
>> to crap out with a SIGILL like Becky's board, but it does do weird
>> things
>> and cause a SIGILL elsewhere during my boot.
>>
>> Reverting this patch from your testing branch allows things to work
>> just fine.
>
> Becky found my thinko, I'll send a new patch later today.
Ben,
FYI, I pulled your updated test branch this morning, booted, and did a
full LTP run on 8572. The results are consistent with the baseline I
have, so it looks like the issue is properly fixed.
-Becky
^ permalink raw reply
* Re: [PATCH 1/5] powerpc/mm: Add MMU features for TLB reservation & Paired MAS registers
From: Kumar Gala @ 2009-08-19 21:37 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <1250666756.4810.16.camel@pasglop>
On Aug 19, 2009, at 2:25 AM, Benjamin Herrenschmidt wrote:
> On Wed, 2009-08-19 at 00:08 -0500, Kumar Gala wrote:
>> Support for TLB reservation (or TLB Write Conditional) and Paired MAS
>> registers are optional for a processor implementation so we handle
>> them via MMU feature sections.
>>
>> We currently only used paired MAS registers to access the full RPN
>> + perm
>> bits that are kept in MAS7||MAS3. We assume that if an
>> implementation has
>> hardware page table at this time it also implements in TLB
>> reservations.
>
> You also need to be careful with this code:
>
> virt_page_table_tlb_miss_done:
>
> /* We have overriden MAS2:EPN but currently our primary TLB miss
> * handler will always restore it so that should not be an issue,
> * if we ever optimize the primary handler to not write MAS2 on
> * some cases, we'll have to restore MAS2:EPN here based on the
> * original fault's DEAR. If we do that we have to modify the
> * ITLB miss handler to also store SRR0 in the exception frame
> * as DEAR.
> *
> * However, one nasty thing we did is we cleared the reservation
> * (well, potentially we did). We do a trick here thus if we
> * are not a level 0 exception (we interrupted the TLB miss) we
> * offset the return address by -4 in order to replay the tlbsrx
> * instruction there
> */
> subf r10,r13,r12
> cmpldi cr0,r10,PACA_EXTLB+EX_TLB_SIZE
> bne- 1f
> ld r11,PACA_EXTLB+EX_TLB_SIZE+EX_TLB_SRR0(r13)
> addi r10,r11,-4
> std r10,PACA_EXTLB+EX_TLB_SIZE+EX_TLB_SRR0(r13)
>
> You may want to make the 3 last lines conditional on having tlbsrx.
The whole thing only ever gets called if we had tlbsrx. so is there
any utility in making a part of conditional on tlbsrx?
> Right now, in the no-tlbsrx. case, what happens is that it will go
> back
> to the previous instruction, an or, which hopefully should be harmless
> -but- this code is nasty enough you really don't want to take that
> sort of chances.
>
> Feel free to add a fat comment next to the ld in the tlbsrx case
> itself
> explaining why those two instructions must be kept together and any
> change here must be reflected in the second level handler.
>
> Cheers,
> Ben.
>
^ permalink raw reply
* Re: powerpc-next rebased
From: Benjamin Herrenschmidt @ 2009-08-19 21:56 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev list
In-Reply-To: <2E8B90A3-A3FD-4EC8-9D41-1BA9E8B261AB@kernel.crashing.org>
On Wed, 2009-08-19 at 08:43 -0500, Kumar Gala wrote:
>
> You screwed it up... :)
>
> The commits you pulled in from me you seem to have changed the
> author
> of the commits which is NOT cool at all. Adding signed-off-by is
> good, changing the committer is ok, but changing the author of the
> commit is not. Please fix this ASAP.
Strange. I just rebased and ammended them, I didn't think that would
change the author :-( I'll try to figure out what went wrong and will
fix it up.
Cheers,
Ben.
> Here's an example (in your tree):
>
> http://git.kernel.org/?p=linux/kernel/git/benh/powerpc.git;a=commitdiff;h=87f1e94c949c28fdaa079d5115a8010c9a40569d
>
> vs the commit in my tree:
>
> http://git.kernel.org/?p=linux/kernel/git/galak/powerpc.git;a=commit;h=d920991f7e02788ba2b468b3023e5bbbc7a32f30
^ permalink raw reply
* Re: [PATCH/RFC] powerpc/mm: Cleanup handling of execute permission
From: Benjamin Herrenschmidt @ 2009-08-19 22:17 UTC (permalink / raw)
To: Becky Bruce; +Cc: linuxppc-dev list, Kumar Gala
In-Reply-To: <16251558-DDF6-46C3-98C2-2FC7CD8A398B@kernel.crashing.org>
On Wed, 2009-08-19 at 15:59 -0500, Becky Bruce wrote:
> On Aug 18, 2009, at 5:33 PM, Benjamin Herrenschmidt wrote:
>
> >
> FYI, I pulled your updated test branch this morning, booted, and did a
> full LTP run on 8572. The results are consistent with the baseline I
> have, so it looks like the issue is properly fixed.
Thanks !
Cheers,
Ben.
^ permalink raw reply
* NAND ECC Error with wrong SMC ording bug
From: Feng Kan @ 2009-08-19 23:16 UTC (permalink / raw)
To: linuxppc-dev; +Cc: u-boot, linux-mtd
In-Reply-To: <1250569482.19007.23.camel@pasglop>
Hi All:
It seems that the ECC correction is broken on the Linux with the 4xx
NDFC driver.
It uses the SMC order when reading the ECC code. 2-1-3
static int ndfc_calculate_ecc(struct mtd_info *mtd,
const u_char *dat, u_char *ecc_code)
{
struct ndfc_controller *ndfc = &ndfc_ctrl;
uint32_t ecc;
uint8_t *p = (uint8_t *)&ecc;
wmb();
ecc = in_be32(ndfc->ndfcbase + NDFC_ECC);
/* The NDFC uses Smart Media (SMC) bytes order */
ecc_code[0] = p[2];
ecc_code[1] = p[1];
ecc_code[2] = p[3];
return 0;
}
However, when in the correction function, the byte address order is
again reverses
causing incorrect byte location.
* performace it does not make any difference
*/
if (eccsize_mult == 1)
byte_addr = (addressbits[b0] << 4) +
addressbits[b1];
>>>> The above really should be byte_addr = (addressbits[b1] << 4) +
addressbits[b0];
else
byte_addr = (addressbits[b2 & 0x3] << 8) +
(addressbits[b1] << 4) +
addressbits[b0];
bit_addr = addressbits[b2 >> 2];
/* flip the bit */
buf[byte_addr] ^= (1 << bit_addr);
printk(KERN_INFO "Corrected b[0] 0x%x b[1]0x%x\n", b0, b1);
printk(KERN_INFO "cal ecc b[0] 0x%x b[1]0x%x\n",
calc_ecc[0] , calc_ecc[1]);
printk(KERN_INFO "read ecc b[0] 0x%x b[1]0x%x\n",
read_ecc[0] , read_ecc[1]);
return 1;
I see other boards using SMC as well, can someone comment on the change
I am proposing.
Should I change the correction algorithm or the calculate function? If
the later is preferred
it would mean the change must be pushed in both U-Boot and Linux.
Feng Kan
AMCC Software
^ permalink raw reply
* Re: [PATCH 1/5] powerpc/mm: Add MMU features for TLB reservation & Paired MAS registers
From: Benjamin Herrenschmidt @ 2009-08-20 0:43 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <AC207041-6DB9-476E-B171-C1F6E10D3FAB@kernel.crashing.org>
On Wed, 2009-08-19 at 16:37 -0500, Kumar Gala wrote:
> On Aug 19, 2009, at 2:25 AM, Benjamin Herrenschmidt wrote:
> The whole thing only ever gets called if we had tlbsrx. so is there
> any utility in making a part of conditional on tlbsrx?
I don't think so ... this is the second level TLB miss handler when
the first level takes a hit on the virtually linear page tables, I
has nothing to do with tlbsrx... however, it does offset the return
address back into the first level handler by -4 to account for
replaying the tlbsrx instruction which you probably don't want to do.
Ben.
^ permalink raw reply
* Re: [PATCH 3/3] agp/uninorth: Unify U3 and pre-U3 insert_memory and remove_memory hooks.
From: Benjamin Herrenschmidt @ 2009-08-20 0:47 UTC (permalink / raw)
To: Michel Dänzer; +Cc: Dave Airlie, linuxppc-dev
In-Reply-To: <1250151313.4992.202.camel@thor>
On Thu, 2009-08-13 at 10:15 +0200, Michel Dänzer wrote:
> On Thu, 2009-08-13 at 17:05 +1000, Benjamin Herrenschmidt wrote:
> > On Tue, 2009-08-04 at 23:51 +0200, Michel Dänzer wrote:
> > > From: Michel Dänzer <daenzer@vmware.com>
> > >
> > > Signed-off-by: Michel Dänzer <daenzer@vmware.com>
> > > ---
> >
> > Hi Michel !
> >
> > While your two previous patches apply just fine, this one doesn't,
> > the uninorth_insert_memory() function seems to be slightly different
> > upstream. Does this depend on some separate yet unapplied patches ?
>
> I previously sent the attached patches to Dave in the course of the
> radeon KMS issues thread. Not sure which of these he's picked up yet, if
> any.
I merged the first two patches in your series, we can sort out the 3rd
one in a second pass on the merge window.
Cheers,
Ben.
>
> > I'm putting 1/3 and 2/3 into my -test branch and they should hit my
> > -next branch in a couple of days.
> >
> > Or do you prefer us to merge that via Dave ?
> >
> > The thing is, stuff in -powerpc is much more likely to get some amount
> > of testing on actual ppc hardware than stuff in random other trees :-)
>
> I'm fine with either way.
>
>
^ permalink raw reply
* Regarding TSI108 ethernet DMA issue
From: Thirumalai Pachamuthu @ 2009-08-20 4:15 UTC (permalink / raw)
To: linuxppc-dev@ozlabs.org
[-- Attachment #1: Type: text/plain, Size: 780 bytes --]
Hi all,
I am trying to port linux 2.6.30 for my TSI108 based custom board
where i am getting the following kernel panic message. I found that it was
due to dma allocation function call particularly dma_alloc_coherent() of
tsi108_open function. When we see the implementation of dma_alloc_coherent.
It was bit changed from the previous linux versions it seems.
The implementation of dma_alloc_coherent was kept on the
arch/powerpc/include/asm/dma-mapping.h file. Earlier implementation is not
considering the first parameter what the tsi108 driver is passing as NULL.
But the current implementation is considering this parameter and because of
this the panic is coming what i believe.
So kindly let me know any patches for this problem or any fixes.
Regards,
T.
[-- Attachment #2: Type: text/html, Size: 870 bytes --]
^ permalink raw reply
* Regarding TSI108 ethernet DMA issue
From: Thirumalai Pachamuthu @ 2009-08-20 4:18 UTC (permalink / raw)
To: linuxppc-dev@ozlabs.org
In-Reply-To: <e1ca2e7b0908192115o2cfa427fof21512757854901a@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2147 bytes --]
Hi all,
I am trying to port linux 2.6.30 for my TSI108 based custom board
where i am getting the following kernel panic message. I found that it was
due to dma allocation function call particularly dma_alloc_coherent() of
tsi108_open function. When we see the implementation of dma_alloc_coherent.
It was bit changed from the previous linux versions it seems.
The implementation of dma_alloc_coherent was kept on the
arch/powerpc/include/asm/dma-mapping.h file. Earlier implementation is not
considering the first parameter what the tsi108 driver is passing as NULL.
But the current implementation is considering this parameter and because of
this the panic is coming what i believe.
So kindly let me know any patches for this problem or any fixes.
------------[ cut here ]------------
Kernel BUG at c019074c [verbose debug info unavailable]
Oops: Exception in kernel mode, sig: 5 [#1]
DPVME0447
NIP: c019074c LR: c019074c CTR: c014ea48
REGS: df82bd80 TRAP: 0700 Not tainted (2.6.30)
MSR: 00029032 <EE,ME,CE,IR,DR> CR: 24000022 XER: 20000000
TASK = df82c000[1] 'swapper' THREAD: df82a000
GPR00: c019074c df82be30 df82c000 00000030 000013e0 ffffffff c014e998
00000035
GPR08: c02f2af0 c02e7bb8 000013e0 c02cd8f4 24000042 00000000 00000002
00000000
GPR16: c02c0000 00000000 00000000 00000000 00000000 0ffaa41c c0300000
00000004
GPR24: 00000000 00000000 c02f0000 c02f0000 df821030 00000000 df821000
df821300
NIP [c019074c] tsi108_open+0x5c/0x90
LR [c019074c] tsi108_open+0x5c/0x90
Call Trace:
[df82be30] [c019074c] tsi108_open+0x5c/0x90 (unreliable)
[df82be50] [c01b1564] dev_open+0xac/0x11c
[df82be70] [c01b1464] dev_change_flags+0x160/0x1b4
[df82be90] [c02bc5f8] ip_auto_config+0x18c/0xe5c
[df82bf50] [c0003c8c] do_one_initcall+0x34/0x1a8
[df82bfd0] [c02a1848] kernel_init+0x9c/0x100
[df82bff0] [c0012064] kernel_thread+0x4c/0x68
Instruction dump:
807f003c 7fc8f378 4beb8d71 7c7d1b79 40820028 80bf003c 3c60c029 7fc6f378
386327c0 90be0028 809f0040 4be90669 <0fe00000> 48000000 80bf003c 3c60c029
---[ end trace dc633a1da0ecdafb ]---
Kernel panic - not syncing: Attempted to kill init!
Rebooting in 180 seconds..
Regards,
T.
[-- Attachment #2: Type: text/html, Size: 2429 bytes --]
^ permalink raw reply
* Re: NAND ECC Error with wrong SMC ording bug
From: Sean MacLennan @ 2009-08-20 4:38 UTC (permalink / raw)
To: Feng Kan; +Cc: linuxppc-dev, linux-mtd, u-boot
In-Reply-To: <4A8C87E6.6070702@amcc.com>
On Wed, 19 Aug 2009 16:16:54 -0700
Feng Kan <fkan@amcc.com> wrote:
> I see other boards using SMC as well, can someone comment on the
> change I am proposing.
> Should I change the correction algorithm or the calculate function?
> If the later is preferred
> it would mean the change must be pushed in both U-Boot and Linux.
Odds are the calculate function is wrong. The correction algo is used
by many nand drivers, I *assume* it is correct. The calculate function
was set to agree with u-boot (1.3.0).
Cheers,
Sean
P.S. Yes, I know the u-boot is an ancient version :(
^ permalink raw reply
* powerpc-next rebased (again)
From: Benjamin Herrenschmidt @ 2009-08-20 4:40 UTC (permalink / raw)
To: linuxppc-dev list; +Cc: linuxppc-dev list, Kumar Gala
In-Reply-To: <4177854C-965A-4A26-A517-B6F0B48703BD@kernel.crashing.org>
Ok so due to screwup mentioned earlier, it's rebased agian :-(
Hopefully that's the last time for very looooooong...
While at it, I removed the lmb kmemleak patch from Michael since
we decided it wasn't a good idea and added Kumar's fix for
assert_pte_locked().
I also updated the test branch with more stuff such as Fujita
IOMMU bits and pieces.
Cheers,
Ben.
^ permalink raw reply
* Re: [U-Boot] NAND ECC Error with wrong SMC ording bug
From: Stefan Roese @ 2009-08-20 5:01 UTC (permalink / raw)
To: u-boot; +Cc: linuxppc-dev, Feng Kan, linux-mtd, Sean MacLennan
In-Reply-To: <20090820003851.1a532444@lappy.seanm.ca>
On Thursday 20 August 2009 06:38:51 Sean MacLennan wrote:
> > I see other boards using SMC as well, can someone comment on the
> > change I am proposing.
> > Should I change the correction algorithm or the calculate function?
> > If the later is preferred
> > it would mean the change must be pushed in both U-Boot and Linux.
>
> Odds are the calculate function is wrong. The correction algo is used
> by many nand drivers, I *assume* it is correct. The calculate function
> was set to agree with u-boot (1.3.0).
Yes, it seems that you changed the order in the calculation function while
reworking the NDFC driver for arch/powerpc. So we should probably change this
order back to the original version. And change it in U-Boot as well.
BTW: I didn't see any problems with ECC so far with the current code. Feng,
how did you spot this problem?
Cheers,
Stefan
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-0 Fax: (+49)-8142-66989-80 Email: office@denx.de
^ permalink raw reply
* Re: [PATCH] Add kmemleak annotations to lmb.c
From: Michael Ellerman @ 2009-08-20 6:01 UTC (permalink / raw)
To: Catalin Marinas; +Cc: David Miller, linuxppc-dev
In-Reply-To: <1250287071.5085.2.camel@pc1117.cambridge.arm.com>
[-- Attachment #1: Type: text/plain, Size: 1698 bytes --]
On Fri, 2009-08-14 at 22:57 +0100, Catalin Marinas wrote:
> On Fri, 2009-08-14 at 12:49 -0700, David Miller wrote:
> > From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> > Date: Fri, 14 Aug 2009 17:56:40 +1000
> >
> > > On Thu, 2009-08-13 at 16:40 +0100, Catalin Marinas wrote:
> > >> On Thu, 2009-08-13 at 13:01 +1000, Michael Ellerman wrote:
> > >> > We don't actually want kmemleak to track the lmb allocations, so we
> > >> > pass min_count as 0. However telling kmemleak about lmb allocations
> > >> > allows it to scan that memory for pointers to other memory that is
> > >> > tracked by kmemleak, ie. slab allocations etc.
> > >>
> > >> Looks alright to me (though I haven't tested it). You can add a
> > >> Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
> > >
> > > Actually, Milton pointed to me that we may not want to allow all
> > > LMB chunks to be scanned by kmemleaks, things like the DART hole
> > > that's taken out of the linear mapping for example may need to
> > > be avoided, though I'm not sure what would be the right way to
> > > do it.
> >
> > I think that annotating LMB for kmemleak may be more problems
> > that it's worth.
>
> BTW, are there many LMB allocations used for storing pointers to other
> objects? If not, it may be worth just annotating those with
> kmemleak_alloc() if you get false positives.
Yeah I think that's probably the safer approach. As Dave says even if
there's nothing obvious, lmb is used for very early allocs which are
more likely to be "special" and cause problems - and only when someone
boots with kmemleak enabled. So we're better to explicitly mark things
we want scanned.
cheers
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox