Re: 2.6.32 Kernel panic - not syncing: Attempted to kill init! Rebooting in 180 seconds..
On Fri, Dec 18, 2009 at 3:38 PM, Zhiyong Wu wrote > On Fri, Dec 18, 2009 at 3:12 PM, Américo Wang > wrote: >> On Fri, Dec 18, 2009 at 12:08 PM, Zhiyong Wu wrote: >>> HI, >>> >>> linux-2.6.32 is compiled on a p6 machine with RH5.4 OS and KVM option is >>> enable. >>> >>> When rebooting this machine, a crash takes place such as: >>> >>> command line: ro console=hvc0 rhgb quiet root=LABEL=/ >>> memory layout at init: >>> memory_limit : (16 MB aligned) >>> alloc_bottom : 019b >>> alloc_top : 0800 >>> alloc_top_hi : 0800 >>> rmo_top : 0800 >>> ram_top : 0800 >>> instantiating rtas at 0x06e1... done >>> boot cpu hw idx >>> copying OF device tree... >>> Building dt strings... >>> Building dt structure... >>> Device tree strings 0x01bc -> 0x01bc15bb >>> Device tree struct 0x01bd -> 0x01bf >>> Calling quiesce... >>> returning from prom_init >>> Red Hat nash version 5.1.19.6 starting >>> ibmvscsi 3002: fast_fail not supported in server >>> sd 0:0:1:0: [sda] Assuming drive cache: write through >>> sd 0:0:1:0: [sda] Assuming drive cache: write through >>> sd 0:0:1:0: [sda] Assuming drive cache: write through >>> insmod: error inserting '/lib/dm-region-hash.ko': -1 File exists >>> mount: could not find filesystem '/dev/root' >>> setuproot: moving /dev failed: No such file or directory >>> setuproot: error mounting /proc: No such file or directory >>> setuproot: error mounting /sys: No such file or directory >>> switchroot: mount failed: No such file or directory >>> Kernel panic - not syncing: Attempted to kill init! >>> Rebooting in 180 seconds..[disconnect] >>> >>> Can anyone give me a warm hand? >> >> Probably this is not a problem of kernel, maybe it's >> a problem of your initial ramdisk, or something wrong with >> your root filesystem. >> >> Does changing "root=LABEL=/" to "root=/dev/XXX" help? >> Where "/dev/XXX" is your root filesystem. >> > > It does'nt still work based on your method. Hmm, so I would guess it's a problem in your initial ramdisk. So you can boot RH5 native kernel with the same boot options but only this one not?? Or maybe the udev your are using doesn't work with 2.6.32? Only another guess... But anyway, checking your 'mkinitrd' would help. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: 2.6.32 Kernel panic - not syncing: Attempted to kill init! Rebooting in 180 seconds..
On Fri, Dec 18, 2009 at 12:08 PM, Zhiyong Wu wrote: > HI, > > linux-2.6.32 is compiled on a p6 machine with RH5.4 OS and KVM option is > enable. > > When rebooting this machine, a crash takes place such as: > > Loading ramdisk... > ramdisk loaded at 0170, size: 2700 Kbytes > OF stdout device is: /vdevice/v...@3000 > Preparing to boot Linux version 2.6.32 (r...@p6ml4n07.clusters.com) > (gcc version 4.1.2 20080704 (Red Hat 4.1.2-46)) #1 SMP Fri Dec 18 > 06:53:27 EST 2009 > Calling ibm,client-architecture-support.../ > Elapsed time since release of system processors: 1212 mins 30 secs > > Config file read, 1024 bytes > > Welcome > Welcome to yaboot version 1.3.13 (Red Hat 1.3.13-8.el5) > Enter "help" to get some basic usage information > boot: linux-32 > Please wait, loading kernel... > Elf64 kernel loaded... > Loading ramdisk... > ramdisk loaded at 0170, size: 2700 Kbytes > OF stdout device is: /vdevice/v...@3000 > Preparing to boot Linux version 2.6.32 (r...@p6ml4n07.clusters.com) > (gcc version 4.1.2 20080704 (Red Hat 4.1.2-46)) #1 SMP Fri Dec 18 > 06:53:27 EST 2009 > Calling ibm,client-architecture-support... done > command line: ro console=hvc0 rhgb quiet root=LABEL=/ > memory layout at init: > memory_limit : (16 MB aligned) > alloc_bottom : 019b > alloc_top : 0800 > alloc_top_hi : 0800 > rmo_top : 0800 > ram_top : 0800 > instantiating rtas at 0x06e1... done > boot cpu hw idx > copying OF device tree... > Building dt strings... > Building dt structure... > Device tree strings 0x01bc -> 0x01bc15bb > Device tree struct 0x01bd -> 0x01bf > Calling quiesce... > returning from prom_init > Red Hat nash version 5.1.19.6 starting > ibmvscsi 3002: fast_fail not supported in server > sd 0:0:1:0: [sda] Assuming drive cache: write through > sd 0:0:1:0: [sda] Assuming drive cache: write through > sd 0:0:1:0: [sda] Assuming drive cache: write through > insmod: error inserting '/lib/dm-region-hash.ko': -1 File exists > mount: could not find filesystem '/dev/root' > setuproot: moving /dev failed: No such file or directory > setuproot: error mounting /proc: No such file or directory > setuproot: error mounting /sys: No such file or directory > switchroot: mount failed: No such file or directory > Kernel panic - not syncing: Attempted to kill init! > Rebooting in 180 seconds..[disconnect] > > Can anyone give me a warm hand? Probably this is not a problem of kernel, maybe it's a problem of your initial ramdisk, or something wrong with your root filesystem. Does changing "root=LABEL=/" to "root=/dev/XXX" help? Where "/dev/XXX" is your root filesystem. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH -tip tracing/kprobes] PPC: Powerpc port of the kprobe-based event tracer
Michael Neuling wrote:
In message <4b29ee5f.9020...@linux.vnet.ibm.com> you wrote:
Hi Michael,
Michael Neuling wrote:
+ * 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 en
try
,
+ * 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);
How do we handle FP args?
Currently this patch does not support FP args.
This might be OK. I don't think we use floating point parameters in any
function definitions in the kernel.
We do use altivec in the raid6 driver (drivers/md/raid6altivec.uc) but
they are static inline, so they probably don't even end up as
functions.
I guess we need to make sure that we're not limiting the interface in
such a way that we can't support it later if the above changes.
regs_get_argument_nth returns an unsigned long which makes returning a
128 bit VMX register impossible. This might be a show stopper for me.
How are the x86 guys dealing with this?
Nope, x86 does not deal with bigger registers (Masami, correct me if I
am wrong). The return data type is opaque to user. Hence this enables us
to handle any such situations in future without effecting user space API.
+ }
+}
+/*
* 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
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Thanks for reviewing.
We are creating a new user space API here, so I'm keen for others to take
a good look at the interface before we commit to something we are going
to have to keep forever.
Who is the main consumer of this (/me is pretty ignorant of kprobes)?
What do they think of the interface?
The user space API are already present in the upstream kernel and
currently only supported architecture is x86. This patch provides ppc
architecture specific interfaces that enables powerpc also in par with x86.
The main consumer would be kernel developers who would like to see
register values, arguments and stack when the probe hits at given text
address.
Mikey
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [POWERPC] add U-Boot bootcount driver.
В Thu, 17 Dec 2009 09:16:07 +0100
Wolfgang Denk пишет:
> Dear Vitaly Bordug,
>
>
> repl: bad addresses:
> linuxppc-...@ozlabs.org -- junk
> after lo...@domain (<) In message <20091216024730.455b9...@vitb-lp>
> you wrote:
> >
> > From: Heiko Schocher
> >
> > 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:
> >
> > bootco...@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
> > Signed-off-by: Wolfgang Denk
> > Signed-off-by: Vitaly Bordyug
>
> I think it would be good if the text of the commit message could be
> reworked by a native English speaker.
>
OK.
> Regarding the subject: it is probably important to point out that this
> driver implements the Linux kernel half of the boot count feature -
> the boot counter can only be reset after it is clear that the
> application has been started and is running correctly, which usually
> can only be determined by the application code itself. Thus the reset
> of the boot counter must be done by application code, which thus needs
> an appropriate driver.
>
I'll rework the commit message to make it more clear, thanks for the
details!
-Vitaly
> > 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.
>
> It's not only useful, it's actually a required feature by the Carrier
> Grade Linux Requirements Definition; see for example document "Carrier
> Grade Linux Requirements Definition Overview V3.0" at
> https://www.linux-foundation.org/images/1/1a/Cgl_req_def_overview_30.pdf
> Page 49:
>
> ID PLT.4.0 (2.3 in v1.1)Boot Cycle Detection
>
> Description: OSDL CGL specifies that carrier grade Linux
> shall provide support for detecting a repeating reboot cycle
> due to recurring failures and going to an offline state if
> this occurs.
>
>
>
>
> Best regards,
>
> Wolfgang Denk
>
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [POWERPC] add U-Boot bootcount driver.
В Thu, 17 Dec 2009 10:34:34 +0100 Wolfram Sang пишет: > On Wed, Dec 16, 2009 at 02:47:30AM +0300, Vitaly Bordug wrote: > > > > From: Heiko Schocher > > > > 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. > > Hmm, both in my inbox and in patchwork, the patch seems line-wrapped. > Also, there are a few printk without loglevel. As probe has access to > a device structure, dev_* should be a nice option here. > OK, makes sense. -Vitaly > Regards, > >Wolfram > signature.asc Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [POWERPC] add U-Boot bootcount driver.
[...]
> > bootco...@0x3eb0 {
> > device_type = "bootcount";
Clear.
>
> No device_type.
>
> > compatible = "uboot,bootcount";
> > reg = <0x3eb0 0x08>;
> > };
>
> This area should also be in the flattened tree's reserved map.
>
Can you elaborate this a little bit? I know about the reserved map by
putting -R4 into device tree cmdline which is apparently not enough :)
Thanks,
-Vitaly
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] ps3_gelic_wireless: Fix build failure due to missing WEXT_PRIV
The option to support the old style PSK interface in the PS3 GELIC wireless drivers requires CONFIG_WEXT_PRIV to be set Signed-off-by: Benjamin Herrenschmidt --- Please send to Linus asap (or I can put it in powerpc.git) as it's breaking one of my test build configs :-) diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig index e58a653..c0ecc77 100644 --- a/drivers/net/Kconfig +++ b/drivers/net/Kconfig @@ -2358,6 +2358,7 @@ config GELIC_WIRELESS config GELIC_WIRELESS_OLD_PSK_INTERFACE bool "PS3 Wireless private PSK interface (OBSOLETE)" depends on GELIC_WIRELESS + select WEXT_PRIV help This option retains the obsolete private interface to pass the PSK from user space programs to the driver. The PSK ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [patch 1/5] powerpc: Sky CPU: redundant or incorrect tests on unsigned
On Fri, 2009-12-18 at 14:40 +1100, Benjamin Herrenschmidt wrote:
> On Thu, 2009-12-17 at 16:44 -0800, a...@linux-foundation.org wrote:
> > From: Roel Kluin
> >
> > count is unsigned and cannot be less than 0.
>
> Is this really a powerpc thing ?
>
> This driver is only build with CONFIG_HDPU_FEATURES and a git grep
> HDPU_FEATURES returns no Kconfig that defines it :-)
>
> I'm happy to apply such a trivial thing but it's weird isn't it ?
Ok so it looks like some old stuff that got removed a long time ago and
never made it to arch/powerpc.
I'll send a patch to just remove the whole driver, it's stale.
Cheers,
Ben.
> Cheers,
> Ben.
>
> > Signed-off-by: Roel Kluin
> > Acked-by: Cyrill Gorcunov
> > Cc: Benjamin Herrenschmidt
> > Cc: Kumar Gala
> > Cc: Brian Waite
> > Signed-off-by: Andrew Morton
> > ---
> >
> > drivers/misc/hdpuftrs/hdpu_cpustate.c |5 -
> > 1 file changed, 5 deletions(-)
> >
> > diff -puN
> > drivers/misc/hdpuftrs/hdpu_cpustate.c~powerpc-sky-cpu-redundant-or-incorrect-tests-on-unsigned
> > drivers/misc/hdpuftrs/hdpu_cpustate.c
> > ---
> > a/drivers/misc/hdpuftrs/hdpu_cpustate.c~powerpc-sky-cpu-redundant-or-incorrect-tests-on-unsigned
> > +++ a/drivers/misc/hdpuftrs/hdpu_cpustate.c
> > @@ -121,8 +121,6 @@ static ssize_t cpustate_read(struct file
> > {
> > unsigned char data;
> >
> > - if (count < 0)
> > - return -EFAULT;
> > if (count == 0)
> > return 0;
> >
> > @@ -137,9 +135,6 @@ static ssize_t cpustate_write(struct fil
> > {
> > unsigned char data;
> >
> > - if (count < 0)
> > - return -EFAULT;
> > -
> > if (count == 0)
> > return 0;
> >
> > _
>
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [patch 1/5] powerpc: Sky CPU: redundant or incorrect tests on unsigned
On Thu, 2009-12-17 at 16:44 -0800, a...@linux-foundation.org wrote:
> From: Roel Kluin
>
> count is unsigned and cannot be less than 0.
Is this really a powerpc thing ?
This driver is only build with CONFIG_HDPU_FEATURES and a git grep
HDPU_FEATURES returns no Kconfig that defines it :-)
I'm happy to apply such a trivial thing but it's weird isn't it ?
Cheers,
Ben.
> Signed-off-by: Roel Kluin
> Acked-by: Cyrill Gorcunov
> Cc: Benjamin Herrenschmidt
> Cc: Kumar Gala
> Cc: Brian Waite
> Signed-off-by: Andrew Morton
> ---
>
> drivers/misc/hdpuftrs/hdpu_cpustate.c |5 -
> 1 file changed, 5 deletions(-)
>
> diff -puN
> drivers/misc/hdpuftrs/hdpu_cpustate.c~powerpc-sky-cpu-redundant-or-incorrect-tests-on-unsigned
> drivers/misc/hdpuftrs/hdpu_cpustate.c
> ---
> a/drivers/misc/hdpuftrs/hdpu_cpustate.c~powerpc-sky-cpu-redundant-or-incorrect-tests-on-unsigned
> +++ a/drivers/misc/hdpuftrs/hdpu_cpustate.c
> @@ -121,8 +121,6 @@ static ssize_t cpustate_read(struct file
> {
> unsigned char data;
>
> - if (count < 0)
> - return -EFAULT;
> if (count == 0)
> return 0;
>
> @@ -137,9 +135,6 @@ static ssize_t cpustate_write(struct fil
> {
> unsigned char data;
>
> - if (count < 0)
> - return -EFAULT;
> -
> if (count == 0)
> return 0;
>
> _
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2 2/2] Crypto: Talitos: Support for Async_tx XOR offload
On Thu, Dec 17, 2009 at 11:45 AM, Kumar Gala wrote: >> The specific case it is needed for Talitos/raid is a channel switch >> interrupt. The interrupt causes the cleanup operation to be run which will >> kick off any pending dependent operations on the xor channel. In the raid >> case we only have callbacks at the end of a chain, so we need the interrupt >> to kick the engine in an operation chain like xor->copy->xor->callback. > > Ok, I'm still confused as to how the DMA interrupt interacts with the > Talitos/raid side of things. The should be completely independent (separate > interrupts, separate IP blocks). > To keep hardware implementation details out of md/raid the async_tx api provides support for managing cross-channel dependency chains. When the raid5 code submits a xor->copy->xor chain the api prepares all the descriptors across all the involved channels but then delays submission as needed to maintain ordering. So at a minimum we need two interrupts in this scenario one from Talitos to kick the submission of the copy-descriptor to fsldma when the first xor completes, and another one to kick the submission of the second xor-descriptor on Talitos when fsldma completes the copy. Needless to say it is more efficient when a channel has all the capabilities, but this channel switch mechanism has proven effective on iop3xx and ppc4xx. -- Dan ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[patch 2/5] mm: add notifier in pageblock isolation for balloon drivers
From: Robert Jennings
Memory balloon drivers can allocate a large amount of memory which is not
movable but could be freed to accomodate memory hotplug remove.
Prior to calling the memory hotplug notifier chain the memory in the
pageblock is isolated. Currently, if the migrate type is not
MIGRATE_MOVABLE the isolation will not proceed, causing the memory removal
for that page range to fail.
Rather than failing pageblock isolation if the migrateteype is not
MIGRATE_MOVABLE, this patch checks if all of the pages in the pageblock,
and not on the LRU, are owned by a registered balloon driver (or other
entity) using a notifier chain. If all of the non-movable pages are owned
by a balloon, they can be freed later through the memory notifier chain
and the range can still be isolated in set_migratetype_isolate().
Signed-off-by: Robert Jennings
Cc: Mel Gorman
Cc: Ingo Molnar
Cc: Brian King
Cc: Paul Mackerras
Cc: Martin Schwidefsky
Cc: Gerald Schaefer
Cc: KAMEZAWA Hiroyuki
Cc: Benjamin Herrenschmidt
Signed-off-by: Andrew Morton
---
drivers/base/memory.c | 19 +
include/linux/memory.h | 27 ++
mm/page_alloc.c| 57 ++-
3 files changed, 96 insertions(+), 7 deletions(-)
diff -puN
drivers/base/memory.c~mm-add-notifier-in-pageblock-isolation-for-balloon-drivers
drivers/base/memory.c
---
a/drivers/base/memory.c~mm-add-notifier-in-pageblock-isolation-for-balloon-drivers
+++ a/drivers/base/memory.c
@@ -63,6 +63,20 @@ void unregister_memory_notifier(struct n
}
EXPORT_SYMBOL(unregister_memory_notifier);
+static ATOMIC_NOTIFIER_HEAD(memory_isolate_chain);
+
+int register_memory_isolate_notifier(struct notifier_block *nb)
+{
+ return atomic_notifier_chain_register(&memory_isolate_chain, nb);
+}
+EXPORT_SYMBOL(register_memory_isolate_notifier);
+
+void unregister_memory_isolate_notifier(struct notifier_block *nb)
+{
+ atomic_notifier_chain_unregister(&memory_isolate_chain, nb);
+}
+EXPORT_SYMBOL(unregister_memory_isolate_notifier);
+
/*
* register_memory - Setup a sysfs device for a memory block
*/
@@ -157,6 +171,11 @@ int memory_notify(unsigned long val, voi
return blocking_notifier_call_chain(&memory_chain, val, v);
}
+int memory_isolate_notify(unsigned long val, void *v)
+{
+ return atomic_notifier_call_chain(&memory_isolate_chain, val, v);
+}
+
/*
* MEMORY_HOTPLUG depends on SPARSEMEM in mm/Kconfig, so it is
* OK to have direct references to sparsemem variables in here.
diff -puN
include/linux/memory.h~mm-add-notifier-in-pageblock-isolation-for-balloon-drivers
include/linux/memory.h
---
a/include/linux/memory.h~mm-add-notifier-in-pageblock-isolation-for-balloon-drivers
+++ a/include/linux/memory.h
@@ -50,6 +50,19 @@ struct memory_notify {
int status_change_nid;
};
+/*
+ * During pageblock isolation, count the number of pages within the
+ * range [start_pfn, start_pfn + nr_pages) which are owned by code
+ * in the notifier chain.
+ */
+#define MEM_ISOLATE_COUNT (1<<0)
+
+struct memory_isolate_notify {
+ unsigned long start_pfn;/* Start of range to check */
+ unsigned int nr_pages; /* # pages in range to check */
+ unsigned int pages_found; /* # pages owned found by callbacks */
+};
+
struct notifier_block;
struct mem_section;
@@ -76,14 +89,28 @@ static inline int memory_notify(unsigned
{
return 0;
}
+static inline int register_memory_isolate_notifier(struct notifier_block *nb)
+{
+ return 0;
+}
+static inline void unregister_memory_isolate_notifier(struct notifier_block
*nb)
+{
+}
+static inline int memory_isolate_notify(unsigned long val, void *v)
+{
+ return 0;
+}
#else
extern int register_memory_notifier(struct notifier_block *nb);
extern void unregister_memory_notifier(struct notifier_block *nb);
+extern int register_memory_isolate_notifier(struct notifier_block *nb);
+extern void unregister_memory_isolate_notifier(struct notifier_block *nb);
extern int register_new_memory(int, struct mem_section *);
extern int unregister_memory_section(struct mem_section *);
extern int memory_dev_init(void);
extern int remove_memory_block(unsigned long, struct mem_section *, int);
extern int memory_notify(unsigned long val, void *v);
+extern int memory_isolate_notify(unsigned long val, void *v);
extern struct memory_block *find_memory_block(struct mem_section *);
#define CONFIG_MEM_BLOCK_SIZE (PAGES_PER_SECTION<
#include
#include
+#include
#include
#include
@@ -5008,23 +5009,65 @@ void set_pageblock_flags_group(struct pa
int set_migratetype_isolate(struct page *page)
{
struct zone *zone;
- unsigned long flags;
+ struct page *curr_page;
+ unsigned long flags, pfn, iter;
+ unsigned long immobile = 0;
+ struct memory_isolate_notify arg;
+ int notifier_ret;
int ret = -EBUSY;
int zone_idx;
zone = page_zone(page);
zo
[patch 3/5] powerpc: make the CMM memory hotplug aware
From: Robert Jennings
The Collaborative Memory Manager (CMM) module allocates individual pages
over time that are not migratable. On a long running system this can
severely impact the ability to find enough pages to support a hotplug
memory remove operation.
This patch adds a memory isolation notifier and a memory hotplug notifier.
The memory isolation notifier will return the number of pages found in
the range specified. This is used to determine if all of the used pages
in a pageblock are owned by the balloon (or other entities in the notifier
chain). The hotplug notifier will free pages in the range which is to be
removed. The priority of this hotplug notifier is low so that it will be
called near last, this helps avoids removing loaned pages in operations
that fail due to other handlers.
CMM activity will be halted when hotplug remove operations are active and
resume activity after a delay period to allow the hypervisor time to
adjust.
Signed-off-by: Robert Jennings
Cc: Mel Gorman
Cc: Ingo Molnar
Cc: Brian King
Cc: Paul Mackerras
Cc: Martin Schwidefsky
Cc: Gerald Schaefer
Cc: KAMEZAWA Hiroyuki
Cc: Benjamin Herrenschmidt
Signed-off-by: Andrew Morton
---
arch/powerpc/platforms/pseries/cmm.c | 254 -
1 file changed, 248 insertions(+), 6 deletions(-)
diff -puN
arch/powerpc/platforms/pseries/cmm.c~powerpc-make-the-cmm-memory-hotplug-aware
arch/powerpc/platforms/pseries/cmm.c
---
a/arch/powerpc/platforms/pseries/cmm.c~powerpc-make-the-cmm-memory-hotplug-aware
+++ a/arch/powerpc/platforms/pseries/cmm.c
@@ -38,19 +38,28 @@
#include
#include
#include
+#include
#include "plpar_wrappers.h"
#define CMM_DRIVER_VERSION "1.0.0"
#define CMM_DEFAULT_DELAY 1
+#define CMM_HOTPLUG_DELAY 5
#define CMM_DEBUG 0
#define CMM_DISABLE0
#define CMM_OOM_KB 1024
#define CMM_MIN_MEM_MB 256
#define KB2PAGES(_p) ((_p)>>(PAGE_SHIFT-10))
#define PAGES2KB(_p) ((_p)<<(PAGE_SHIFT-10))
+/*
+ * The priority level tries to ensure that this notifier is called as
+ * late as possible to reduce thrashing in the shared memory pool.
+ */
+#define CMM_MEM_HOTPLUG_PRI1
+#define CMM_MEM_ISOLATE_PRI15
static unsigned int delay = CMM_DEFAULT_DELAY;
+static unsigned int hotplug_delay = CMM_HOTPLUG_DELAY;
static unsigned int oom_kb = CMM_OOM_KB;
static unsigned int cmm_debug = CMM_DEBUG;
static unsigned int cmm_disabled = CMM_DISABLE;
@@ -65,6 +74,10 @@ MODULE_VERSION(CMM_DRIVER_VERSION);
module_param_named(delay, delay, uint, S_IRUGO | S_IWUSR);
MODULE_PARM_DESC(delay, "Delay (in seconds) between polls to query hypervisor
paging requests. "
"[Default=" __stringify(CMM_DEFAULT_DELAY) "]");
+module_param_named(hotplug_delay, hotplug_delay, uint, S_IRUGO | S_IWUSR);
+MODULE_PARM_DESC(delay, "Delay (in seconds) after memory hotplug remove "
+"before loaning resumes. "
+"[Default=" __stringify(CMM_HOTPLUG_DELAY) "]");
module_param_named(oom_kb, oom_kb, uint, S_IRUGO | S_IWUSR);
MODULE_PARM_DESC(oom_kb, "Amount of memory in kb to free on OOM. "
"[Default=" __stringify(CMM_OOM_KB) "]");
@@ -92,6 +105,9 @@ static unsigned long oom_freed_pages;
static struct cmm_page_array *cmm_page_list;
static DEFINE_SPINLOCK(cmm_lock);
+static DEFINE_MUTEX(hotplug_mutex);
+static int hotplug_occurred; /* protected by the hotplug mutex */
+
static struct task_struct *cmm_thread_ptr;
/**
@@ -110,6 +126,17 @@ static long cmm_alloc_pages(long nr)
cmm_dbg("Begin request for %ld pages\n", nr);
while (nr) {
+ /* Exit if a hotplug operation is in progress or occurred */
+ if (mutex_trylock(&hotplug_mutex)) {
+ if (hotplug_occurred) {
+ mutex_unlock(&hotplug_mutex);
+ break;
+ }
+ mutex_unlock(&hotplug_mutex);
+ } else {
+ break;
+ }
+
addr = __get_free_page(GFP_NOIO | __GFP_NOWARN |
__GFP_NORETRY | __GFP_NOMEMALLOC);
if (!addr)
@@ -119,8 +146,9 @@ static long cmm_alloc_pages(long nr)
if (!pa || pa->index >= CMM_NR_PAGES) {
/* Need a new page for the page list. */
spin_unlock(&cmm_lock);
- npa = (struct cmm_page_array *)__get_free_page(GFP_NOIO
| __GFP_NOWARN |
-
__GFP_NORETRY | __GFP_NOMEMALLOC);
+ npa = (struct cmm_page_array *)__get_free_page(
+ GFP_NOIO | __GFP_NOWARN |
+ __GFP_NORETRY | __GFP_NOMEMALLOC);
if (!npa) {
pr_info("%s: Can not allo
[patch 5/5] powerpc/85xx: wrong variable returned on error
From: Roel Kluin The wrong variable was returned in the case of an error. Signed-off-by: Roel Kluin Cc: Kumar Gala Cc: Benjamin Herrenschmidt Signed-off-by: Andrew Morton --- arch/powerpc/platforms/85xx/mpc85xx_mds.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff -puN arch/powerpc/platforms/85xx/mpc85xx_mds.c~powerpc-85xx-wrong-variable-returned-on-error arch/powerpc/platforms/85xx/mpc85xx_mds.c --- a/arch/powerpc/platforms/85xx/mpc85xx_mds.c~powerpc-85xx-wrong-variable-returned-on-error +++ a/arch/powerpc/platforms/85xx/mpc85xx_mds.c @@ -86,7 +86,7 @@ static int mpc8568_fixup_125_clock(struc scr = phy_read(phydev, MV88E_SCR); if (scr < 0) - return err; + return scr; err = phy_write(phydev, MV88E_SCR, scr | 0x0008); _ ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[patch 4/5] iseries: convert to proc_fops
From: Alexey Dobriyan
Signed-off-by: Alexey Dobriyan
Cc: Benjamin Herrenschmidt
Cc: Michael Ellerman
Signed-off-by: Andrew Morton
---
arch/powerpc/platforms/iseries/mf.c | 147 ++
1 file changed, 83 insertions(+), 64 deletions(-)
diff -puN arch/powerpc/platforms/iseries/mf.c~iseries-convert-to-proc_fops
arch/powerpc/platforms/iseries/mf.c
--- a/arch/powerpc/platforms/iseries/mf.c~iseries-convert-to-proc_fops
+++ a/arch/powerpc/platforms/iseries/mf.c
@@ -855,59 +855,58 @@ static int mf_get_boot_rtc(struct rtc_ti
}
#ifdef CONFIG_PROC_FS
-
-static int proc_mf_dump_cmdline(char *page, char **start, off_t off,
- int count, int *eof, void *data)
+static int mf_cmdline_proc_show(struct seq_file *m, void *v)
{
- int len;
- char *p;
+ char *page, *p;
struct vsp_cmd_data vsp_cmd;
int rc;
dma_addr_t dma_addr;
/* The HV appears to return no more than 256 bytes of command line */
- if (off >= 256)
- return 0;
- if ((off + count) > 256)
- count = 256 - off;
+ page = kmalloc(256, GFP_KERNEL);
+ if (!page)
+ return -ENOMEM;
- dma_addr = iseries_hv_map(page, off + count, DMA_FROM_DEVICE);
- if (dma_addr == DMA_ERROR_CODE)
+ dma_addr = iseries_hv_map(page, 256, DMA_FROM_DEVICE);
+ if (dma_addr == DMA_ERROR_CODE) {
+ kfree(page);
return -ENOMEM;
- memset(page, 0, off + count);
+ }
+ memset(page, 0, 256);
memset(&vsp_cmd, 0, sizeof(vsp_cmd));
vsp_cmd.cmd = 33;
vsp_cmd.sub_data.kern.token = dma_addr;
vsp_cmd.sub_data.kern.address_type = HvLpDma_AddressType_TceIndex;
- vsp_cmd.sub_data.kern.side = (u64)data;
- vsp_cmd.sub_data.kern.length = off + count;
+ vsp_cmd.sub_data.kern.side = (u64)m->private;
+ vsp_cmd.sub_data.kern.length = 256;
mb();
rc = signal_vsp_instruction(&vsp_cmd);
- iseries_hv_unmap(dma_addr, off + count, DMA_FROM_DEVICE);
- if (rc)
+ iseries_hv_unmap(dma_addr, 256, DMA_FROM_DEVICE);
+ if (rc) {
+ kfree(page);
return rc;
- if (vsp_cmd.result_code != 0)
+ }
+ if (vsp_cmd.result_code != 0) {
+ kfree(page);
return -ENOMEM;
+ }
p = page;
- len = 0;
- while (len < (off + count)) {
- if ((*p == '\0') || (*p == '\n')) {
- if (*p == '\0')
- *p = '\n';
- p++;
- len++;
- *eof = 1;
+ while (p - page < 256) {
+ if (*p == '\0' || *p == '\n') {
+ *p = '\n';
break;
}
p++;
- len++;
- }
- if (len < off) {
- *eof = 1;
- len = 0;
}
- return len;
+ seq_write(m, page, p - page);
+ kfree(page);
+ return 0;
+}
+
+static int mf_cmdline_proc_open(struct inode *inode, struct file *file)
+{
+ return single_open(file, mf_cmdline_proc_show, PDE(inode)->data);
}
#if 0
@@ -962,10 +961,8 @@ static int proc_mf_dump_vmlinux(char *pa
}
#endif
-static int proc_mf_dump_side(char *page, char **start, off_t off,
- int count, int *eof, void *data)
+static int mf_side_proc_show(struct seq_file *m, void *v)
{
- int len;
char mf_current_side = ' ';
struct vsp_cmd_data vsp_cmd;
@@ -989,21 +986,17 @@ static int proc_mf_dump_side(char *page,
}
}
- len = sprintf(page, "%c\n", mf_current_side);
+ seq_printf(m, "%c\n", mf_current_side);
+ return 0;
+}
- if (len <= (off + count))
- *eof = 1;
- *start = page + off;
- len -= off;
- if (len > count)
- len = count;
- if (len < 0)
- len = 0;
- return len;
+static int mf_side_proc_open(struct inode *inode, struct file *file)
+{
+ return single_open(file, mf_side_proc_show, NULL);
}
-static int proc_mf_change_side(struct file *file, const char __user *buffer,
- unsigned long count, void *data)
+static ssize_t mf_side_proc_write(struct file *file, const char __user *buffer,
+ size_t count, loff_t *pos)
{
char side;
u64 newSide;
@@ -1041,6 +1034,15 @@ static int proc_mf_change_side(struct fi
return count;
}
+static const struct file_operations mf_side_proc_fops = {
+ .owner = THIS_MODULE,
+ .open = mf_side_proc_open,
+ .read = seq_read,
+ .llseek = seq_lseek,
+ .release= single_release,
+ .write = mf_side_proc_write,
+};
+
#if 0
static void mf_getSrcHistory(char *buffer, int size)
{
@@ -1087,8 +1089,7 @@ static void mf_get
[patch 1/5] powerpc: Sky CPU: redundant or incorrect tests on unsigned
From: Roel Kluin
count is unsigned and cannot be less than 0.
Signed-off-by: Roel Kluin
Acked-by: Cyrill Gorcunov
Cc: Benjamin Herrenschmidt
Cc: Kumar Gala
Cc: Brian Waite
Signed-off-by: Andrew Morton
---
drivers/misc/hdpuftrs/hdpu_cpustate.c |5 -
1 file changed, 5 deletions(-)
diff -puN
drivers/misc/hdpuftrs/hdpu_cpustate.c~powerpc-sky-cpu-redundant-or-incorrect-tests-on-unsigned
drivers/misc/hdpuftrs/hdpu_cpustate.c
---
a/drivers/misc/hdpuftrs/hdpu_cpustate.c~powerpc-sky-cpu-redundant-or-incorrect-tests-on-unsigned
+++ a/drivers/misc/hdpuftrs/hdpu_cpustate.c
@@ -121,8 +121,6 @@ static ssize_t cpustate_read(struct file
{
unsigned char data;
- if (count < 0)
- return -EFAULT;
if (count == 0)
return 0;
@@ -137,9 +135,6 @@ static ssize_t cpustate_write(struct fil
{
unsigned char data;
- if (count < 0)
- return -EFAULT;
-
if (count == 0)
return 0;
_
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 3/3] mpc8xxx_gpio: add interrupt support
> "Peter" == Peter Korsgaard writes: > "Kumar" == Kumar Gala writes: Peter> Hi, Kumar> We need a binding document to go with this. Peter> Ok, but where should it go? In the existing Peter> powerpc/dts-bindings/fsl/8xxx_gpio.txt or somewhere seperate? I don't Peter> see any other interrupt controller documentation besides the stuff in Peter> booting-without-of.txt Any comments? -- Bye, Peter Korsgaard ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Problem with mini-PCI-E slot on P2020RDB
Hi, Kumar Kumar Gala wrote: On Dec 17, 2009, at 2:59 AM, Mahajan Vivek-B08308 wrote: Thanks a lot. If I understand you correctly, the only way I can get ath9k driver to work on this board using legacy interrupts is to wait for a hardware fix. Right ? Correct I'm confused. What's the issue with IRQ0 on the P2020RDB? Is it used for another purpose? There's a problem with IRQ0 with respect to mini-PCI-E slot. I have Atheros wireless card plugged into it. ath9k wireless driver for this card uses legacy PCI-E interrupts, and I get "irq 16: nobody cared" message when driver executes request_irq(). Vivek has come to a conclusion that the problem is related to incorrect IRQ0 routing for mini-PCI-E slot on P2020RDB. Felix. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [Patch 1/1] PPC64-HWBKPT: Implement hw-breakpoints for PPC64
On Mon, Dec 14, 2009 at 11:26:26AM -0800, Roland McGrath wrote: > I understand the reason for using stepping. (I have advised in the past > that I thought this magical implicit step logic was too hairy to roll in > under the covers and that a low-level facility expressing the different > hardware semantics to a kernel API would be OK. I do agree with the > motivation of cross-arch uniformity of the semantics. I don't object to > making it magically right--I just expressed general skepticism/fear about > getting that right so that I didn't want to try writing that magic. Now > I'm just responding about the particular details I've noticed about that > can of worms. It's certainly great if you can resolve all that. But I'll > note that I am still by no means confident that the details I have raised > cover all the worms in that can.) > > What remains less than clear is how preemption relates. For any per-thread > hw_breakpoint, there is no high-level reason to care one way or the other. > The thread, its HW breakpoints, its register state including state of > stepping, are all part of per-thread state and no reason to do any less (or > more) preemption than normally happens. > I get that reasoning now...I'd been unduly worried about pre-emption and hence the introduction of pre-emption disabled state. But of course, in the existing design, the per-cpu variables would be affected because if pre-emption was to occur. I'll see how that can be factored in, while retaining the abstraction provided by the interfaces. > > Disabling pre-emption is necessary to ensure that hw-breakpoints are > > enabled immediately after the causative instruction has finished > > execution (the control flow may go astray if pre-emption occurs between > > i1 and i2). > > I don't understand what "go astray" means here. The only thing I can think > of is the effect on any per-cpu variables you are using in hw_breakpoint > implementation. > As stated above, I was worried about a pre-emption happening between a return from breakpoint exception handler and the execution of the causative instructionbut as I learn, it seems fine now. It is just that the kernel code needs to be tweaked keeping this in mind. Thanks, K.Prasad ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2 2/2] Crypto: Talitos: Support for Async_tx XOR offload
On Dec 17, 2009, at 11:44 AM, Dan Williams wrote: > Ira W. Snyder wrote: >> Yes, I have used the device_prep_dma_interrupt() functionality quite a >> while back. However, I found it to be pretty much useless. > > The specific case it is needed for Talitos/raid is a channel switch > interrupt. The interrupt causes the cleanup operation to be run which will > kick off any pending dependent operations on the xor channel. In the raid > case we only have callbacks at the end of a chain, so we need the interrupt > to kick the engine in an operation chain like xor->copy->xor->callback. Ok, I'm still confused as to how the DMA interrupt interacts with the Talitos/raid side of things. The should be completely independent (separate interrupts, separate IP blocks). - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc: gamecube/wii: fix off-by-one error in ugecon/usbgecko_udbg
The retry logic in ug_putc() is broken. If the TX fifo is not ready and the counter runs out it will have a value of -1 and no transfer should be attempted. Also, a counter with a value of 0 means that the TX fifo got ready in the last try and the transfer should be attempted. Reported-by: "Juha Leppanen" Signed-off-by: "Juha Leppanen" Signed-off-by: Albert Herranz --- arch/powerpc/boot/ugecon.c |2 +- arch/powerpc/platforms/embedded6xx/usbgecko_udbg.c |2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/powerpc/boot/ugecon.c b/arch/powerpc/boot/ugecon.c index 50609ea..8f2a6b3 100644 --- a/arch/powerpc/boot/ugecon.c +++ b/arch/powerpc/boot/ugecon.c @@ -86,7 +86,7 @@ static void ug_putc(char ch) while (!ug_is_txfifo_ready() && count--) barrier(); - if (count) + if (count >= 0) ug_raw_putc(ch); } diff --git a/arch/powerpc/platforms/embedded6xx/usbgecko_udbg.c b/arch/powerpc/platforms/embedded6xx/usbgecko_udbg.c index edc956c..20a8ed9 100644 --- a/arch/powerpc/platforms/embedded6xx/usbgecko_udbg.c +++ b/arch/powerpc/platforms/embedded6xx/usbgecko_udbg.c @@ -120,7 +120,7 @@ static void ug_putc(char ch) while (!ug_is_txfifo_ready() && count--) barrier(); - if (count) + if (count >= 0) ug_raw_putc(ch); } -- 1.6.3.3 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Need advice on changing MPC5200B UART prescaler
Hi all,
I would like to be able to set a baud rate of 460800 for modem that we are
testing. With the actual prescaler of 32 and a IPB frequency of 84MHz
I got a 5.1% error (437500) vs a 0.9% error (456522) if I could use the
prescaler of 4. See MPC5200B user manual page 15-46 for the calculation
formula and page 15-12 for the CSR description.
Currently the code for the kernel we are using here, (2.6.29.2) seams not to
take a prescaler of 4 into account.
Line 249 of mpc52xx_uart.c
http://lxr.linux.no/linux+v2.6.29.2/drivers/serial/mpc52xx_uart.c#L249
/* Search for bus-frequency property in this node or a parent */
static unsigned long mpc52xx_getuartclk(void *p)
{
/*
* 5200 UARTs have a / 32 prescaler
* but the generic serial code assumes 16
* so return ipb freq / 2
*/
return mpc52xx_find_ipb_freq(p) / 2;
}
How could I make it use the prescaler of 4 without breaking anything that we
currently have working ?
I doubt that simply doing return mpc52xx_find_ipb_freq(p) / 4 would do the
trick ...
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2 2/2] Crypto: Talitos: Support for Async_tx XOR offload
Ira W. Snyder wrote: Yes, I have used the device_prep_dma_interrupt() functionality quite a while back. However, I found it to be pretty much useless. The specific case it is needed for Talitos/raid is a channel switch interrupt. The interrupt causes the cleanup operation to be run which will kick off any pending dependent operations on the xor channel. In the raid case we only have callbacks at the end of a chain, so we need the interrupt to kick the engine in an operation chain like xor->copy->xor->callback. -- Dan ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2 2/2] Crypto: Talitos: Support for Async_tx XOR offload
On Dec 17, 2009, at 11:09 AM, Ira W. Snyder wrote: > On Wed, Dec 16, 2009 at 03:47:48PM -0700, Dan Williams wrote: >> Kumar Gala wrote: > Changes with respect to v1 as per comments received > o. Rebased to linux-next as of 20091216 > o. The selection is based exclusive of fsldma > o. Intoduced a new Kernel Configuration variable > *. This enables selecting the Cryptographic functionality > of Talitos along with fsldma. > *. Disables the XOR parity calculation offload, if fsldma enabled > either as kernel in-built or as a module > *. Once the inter-operability with fsldma is resolved, this option > can be removed wait, why can't the interoperability bug be fixed in the first place? >>> >>> I agree w/Kim. We need to better understand what the bug is and how to >>> reproduce it so we can get to the root cause. >>> >>> Paper taping over it by disabling fsldma is not the right solution. >> >> Hopefully this prompts fsldma authors to get involved because the >> interoperability issue has been out there without comment*, just >> band-aids, since October. >> >> -- >> Dan >> >> * well one comment from Ira saying the interrupt functionality worked >> for him. > > Yes, I have used the device_prep_dma_interrupt() functionality quite a > while back. However, I found it to be pretty much useless. Any > functionality I need is covered by adding a callback to the last DMA > memcpy() operation. Since the operations happen in-order, I can be sure > that the entire set of memcpy()s cas completed. I never needed the > capability to generate an interrupt without a memcpy(). > > I agree that the fsldma driver could use some love. There are places > where I am still not confident in the locking. Perhaps I can find some > time over Christmas to work on it, but I need someone with 85xx/86xx > hardware to test the changes. I only have 83xx hardware. I can test on 85xx/86xx if you work up some patches. - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2 2/2] Crypto: Talitos: Support for Async_tx XOR offload
On Wed, Dec 16, 2009 at 03:47:48PM -0700, Dan Williams wrote: > Kumar Gala wrote: > >>> Changes with respect to v1 as per comments received > >>> o. Rebased to linux-next as of 20091216 > >>> o. The selection is based exclusive of fsldma > >>> o. Intoduced a new Kernel Configuration variable > >>> *. This enables selecting the Cryptographic functionality > >>> of Talitos along with fsldma. > >>> *. Disables the XOR parity calculation offload, if fsldma enabled > >>> either as kernel in-built or as a module > >>> *. Once the inter-operability with fsldma is resolved, this option > >>> can be removed > >> wait, why can't the interoperability bug be fixed in the first place? > > > > I agree w/Kim. We need to better understand what the bug is and how to > > reproduce it so we can get to the root cause. > > > > Paper taping over it by disabling fsldma is not the right solution. > > Hopefully this prompts fsldma authors to get involved because the > interoperability issue has been out there without comment*, just > band-aids, since October. > > -- > Dan > > * well one comment from Ira saying the interrupt functionality worked > for him. Yes, I have used the device_prep_dma_interrupt() functionality quite a while back. However, I found it to be pretty much useless. Any functionality I need is covered by adding a callback to the last DMA memcpy() operation. Since the operations happen in-order, I can be sure that the entire set of memcpy()s cas completed. I never needed the capability to generate an interrupt without a memcpy(). I agree that the fsldma driver could use some love. There are places where I am still not confident in the locking. Perhaps I can find some time over Christmas to work on it, but I need someone with 85xx/86xx hardware to test the changes. I only have 83xx hardware. Ira ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Problem with mini-PCI-E slot on P2020RDB
On Dec 17, 2009, at 2:59 AM, Mahajan Vivek-B08308 wrote: >> >> Thanks a lot. If I understand you correctly, the only way I >> can get ath9k driver to work on this board using legacy >> interrupts is to wait for a hardware fix. Right ? > > Correct I'm confused. What's the issue with IRQ0 on the P2020RDB? Is it used for another purpose? - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] PowerPC: const intspec pointers
Hello Grant, On Tuesday 15 December 2009 20:50:05 Grant Likely wrote: > Yes, I'm using the driver in a couple of projects. It works for me > for both RX and TX (although TX+DMA has been troublesome). That's what I found out. > The test driver on the other hand is pretty poor code. Don't expect > much from it other than some hints. There's a reason I didn't merge > that chunk. I brought it up to speed before using it. > Yes, please post the patches and cc: me. I'll review, test, and make > comments. I hope it's ok that I've copied them to my web space instead of providing patches in a mail. The URL is: http://www.fietze-home.de/telemotive/linux-2.6-telemotive-mpc.git Branches: benh-next-lpbfifo the modified version of the LocalPlus platform driver benh-next-localplus-test your old test driver, now using the platform driver Both branches are on top of the benh next branch. I could only test the driver using fifo and bcom mode in read mode, using your old test driver, because I currently do not yet have a target with a writeable device on the LocalPlus. The test ran fine using different transer sizes starting at 4 up to 128KiB. I will now port our FPGA driver to use the platform driver, which can deliver a very high load, and supports writing. The biggest problem using DMA is the unpredictable order of arrival of the two interrupts. They both depend on the appropriate load of the system generating them. In the case of the BestComm a parallel load on e.g. FEC or ATA can delay the bcom gen bd interrupt until it's task gets scheduled again, which can take "some time" due its low BestComm prio of 2. The second problem was, that the original driver does not use the flush bit to avoid stale RX data. Roman -- Roman FietzeTelemotive AG Büro Mühlhausen Breitwiesen 73347 Mühlhausen Tel.: +49(0)7335/18493-45http://www.telemotive.de ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH -tip tracing/kprobes] PPC: Powerpc port of the kprobe-based event tracer
In message <4b29ee5f.9020...@linux.vnet.ibm.com> you wrote:
> Hi Michael,
>
> Michael Neuling wrote:
> >> 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
> >> +#include
> >
> > Includes should be at the start of the file
> >
> The compilation throws many errors when moved to start of the file. This
> file has lots of #ifdef and found this place to be perfect for compilation.
Ok, no problem.
>
> >> +/**
> >> + * 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 en
try
> > ,
> >> + * 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);
> >
> > How do we handle FP args?
>
> Currently this patch does not support FP args.
This might be OK. I don't think we use floating point parameters in any
function definitions in the kernel.
We do use altivec in the raid6 driver (drivers/md/raid6altivec.uc) but
they are static inline, so they probably don't even end up as
functions.
I guess we need to make sure that we're not limiting the interface in
such a way that we can't support it later if the above changes.
regs_get_argument_nth returns an unsigned long which makes returning a
128 bit VMX register impossible. This might be a show stopper for me.
How are the x86 guys dealing with this?
> >
> >> + }
> >> +}
> >> +/*
> >> * 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
> >>
> >> ___
> >> Linuxppc-dev mailing list
> >> Linuxppc-dev@lists.ozlabs.org
> >> https://lists.ozlab
Re: [PATCH -tip tracing/kprobes] PPC: Powerpc port of the kprobe-based event tracer
In message <4b29c3e3.3060...@redhat.com> you wrote:
> Hi Michael,
>
> Michael Neuling wrote:
> >> +
> >> +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,
> >
> > Do we need to add something for FP and VMX registers here?
>
> Hmm, are FP and VMX registers actually used inside kernel on PPC?
Yes. Look for enable_kernel_fp/altivec
Mikey
> Actually, the main purpose of this code is to provide accessing method
> of in-kernel pt_regs fields (registers used in kernel) by name.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [POWERPC] add U-Boot bootcount driver.
On Wed, Dec 16, 2009 at 02:47:30AM +0300, Vitaly Bordug wrote: > > From: Heiko Schocher > > 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. Hmm, both in my inbox and in patchwork, the patch seems line-wrapped. Also, there are a few printk without loglevel. As probe has access to a device structure, dev_* should be a nice option here. Regards, Wolfram -- Pengutronix e.K. | Wolfram Sang| Industrial Linux Solutions | http://www.pengutronix.de/ | signature.asc Description: Digital signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: Problem with mini-PCI-E slot on P2020RDB
> From: Felix Radensky [mailto:fe...@embedded-sol.com] > Sent: Thursday, December 17, 2009 2:26 PM > > > Yes, I've enabled that bit, but didn't get any interrupt. Thanks for trying. > > Thanks a lot. If I understand you correctly, the only way I > can get ath9k driver to work on this board using legacy > interrupts is to wait for a hardware fix. Right ? Correct > > Felix. > Thanks, Vivek ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Problem with mini-PCI-E slot on P2020RDB
Mahajan Vivek-B08308 wrote: From: linuxppc-dev-bounces+vivek.mahajan=freescale@lists.ozlabs. org [mailto:linuxppc-dev-bounces+vivek.mahajan=freescale@lists .ozlabs.org] On Behalf Of Felix Radensky Sent: Thursday, December 17, 2009 12:52 PM I just noticed a MSI enable bit in drivers/net/wireless/ath/ath9k/reg.h 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 0x0001 According to ath9k developers adding MSI support to the driver is not trivial. They've tried once, it didn't work and they gave up. Any chance I can use mini-PCI-E slot without MSI ? So, even after enabling the above bit, there were no MSI interrupts from this card. If we look at some of the GbE or SATA drivers, adding MSI is not that hard. ath9k can be an exception. Yes, I've enabled that bit, but didn't get any interrupt. I reported this issue to the p2020 board designer; but unfortunately he is out until 1/4/10. It could be a missing pull-up issue at IRQ0 or some thing else, I don't know. Thanks a lot. If I understand you correctly, the only way I can get ath9k driver to work on this board using legacy interrupts is to wait for a hardware fix. Right ? Felix. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH -tip tracing/kprobes] PPC: Powerpc port of the kprobe-based event tracer
Hi Michael,
Michael Neuling wrote:
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
+#include
Includes should be at the start of the file
The compilation throws many errors when moved to start of the file. This
file has lots of #ifdef and found this place to be perfect for compilation.
+/**
+ * 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);
How do we handle FP args?
Currently this patch does not support FP args.
+ }
+}
+/*
* 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
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Thanks for reviewing.
Thanks,
-Mahesh.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [POWERPC] add U-Boot bootcount driver.
Dear Vitaly Bordug,
repl: bad addresses:
linuxppc-...@ozlabs.org -- junk after
lo...@domain (<)
In message <20091216024730.455b9...@vitb-lp> you wrote:
>
> From: Heiko Schocher
>
> 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:
>
> bootco...@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
> Signed-off-by: Wolfgang Denk
> Signed-off-by: Vitaly Bordyug
I think it would be good if the text of the commit message could be
reworked by a native English speaker.
Regarding the subject: it is probably important to point out that this
driver implements the Linux kernel half of the boot count feature -
the boot counter can only be reset after it is clear that the
application has been started and is running correctly, which usually
can only be determined by the application code itself. Thus the reset
of the boot counter must be done by application code, which thus needs
an appropriate driver.
> 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.
It's not only useful, it's actually a required feature by the Carrier
Grade Linux Requirements Definition; see for example document "Carrier
Grade Linux Requirements Definition Overview V3.0" at
https://www.linux-foundation.org/images/1/1a/Cgl_req_def_overview_30.pdf
Page 49:
ID PLT.4.0 (2.3 in v1.1)Boot Cycle Detection
Description: OSDL CGL specifies that carrier grade Linux
shall provide support for detecting a repeating reboot cycle
due to recurring failures and going to an offline state if
this occurs.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
I read part of it all the way through.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: Problem with mini-PCI-E slot on P2020RDB
> From: > linuxppc-dev-bounces+vivek.mahajan=freescale@lists.ozlabs. > org > [mailto:linuxppc-dev-bounces+vivek.mahajan=freescale@lists > .ozlabs.org] On Behalf Of Felix Radensky > Sent: Thursday, December 17, 2009 12:52 PM > > > > I just noticed a MSI enable bit in > > drivers/net/wireless/ath/ath9k/reg.h > > 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 > 0x0001 > > > According to ath9k developers adding MSI support to the > driver is not trivial. > They've tried once, it didn't work and they gave up. Any > chance I can use mini-PCI-E slot without MSI ? So, even after enabling the above bit, there were no MSI interrupts from this card. If we look at some of the GbE or SATA drivers, adding MSI is not that hard. ath9k can be an exception. I reported this issue to the p2020 board designer; but unfortunately he is out until 1/4/10. It could be a missing pull-up issue at IRQ0 or some thing else, I don't know. > > Thanks. > > Felix. Thanks, Vivek ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
