* [PATCH 7/7] fdt.c: Refactor unflatten_device_tree and add fdt_unflatten_tree
From: Stephen Neuendorffer @ 2010-11-18 23:55 UTC (permalink / raw)
To: grant.likely, dirk.brandewie, devicetree-discuss, linuxppc-dev,
microblaze-uclinux
In-Reply-To: <1290124502-13125-7-git-send-email-stephen.neuendorffer@xilinx.com>
unflatten_device_tree has two dependencies on things that happen
during boot time. Firstly, it references the initial device tree
directly. Secondly, it allocates memory using the early boot
allocator. This patch factors out these dependencies and uses
the new __unflatten_device_tree function to implement a driver-visible
fdt_unflatten_tree function, which can be used to unflatten a
blob after boot time.
Signed-off-by: Stephen Neuendorffer <stephen.neuendorffer@xilinx.com>
--
V2: remove extra __va() call
make dt_alloc functions return void *. This doesn't fix the general
strangeness in this code that constantly casts back and forth between
unsigned long and __be32 *
---
drivers/of/fdt.c | 149 +++++++++++++++++++++++++++++++----------------
include/linux/of_fdt.h | 2 +
2 files changed, 100 insertions(+), 51 deletions(-)
diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
index 236a8c9..e29dbe2 100644
--- a/drivers/of/fdt.c
+++ b/drivers/of/fdt.c
@@ -11,10 +11,12 @@
#include <linux/kernel.h>
#include <linux/initrd.h>
+#include <linux/module.h>
#include <linux/of.h>
#include <linux/of_fdt.h>
#include <linux/string.h>
#include <linux/errno.h>
+#include <linux/slab.h>
#ifdef CONFIG_PPC
#include <asm/machdep.h>
@@ -312,6 +314,94 @@ unsigned long unflatten_dt_node(struct boot_param_header *blob,
return mem;
}
+/**
+ * __unflatten_device_tree - create tree of device_nodes from flat blob
+ *
+ * unflattens a device-tree, creating the
+ * tree of struct device_node. It also fills the "name" and "type"
+ * pointers of the nodes so the normal device-tree walking functions
+ * can be used.
+ * @blob: The blob to expand
+ * @mynodes: The device_node tree created by the call
+ * @dt_alloc: An allocator that provides a virtual address to memory
+ * for the resulting tree
+ */
+void __unflatten_device_tree(struct boot_param_header *blob,
+ struct device_node **mynodes,
+ void * (*dt_alloc)(u64 size, u64 align))
+{
+ unsigned long start, mem, size;
+ struct device_node **allnextp = mynodes;
+
+ pr_debug(" -> unflatten_device_tree()\n");
+
+ if (!blob) {
+ pr_debug("No device tree pointer\n");
+ return;
+ }
+
+ pr_debug("Unflattening device tree:\n");
+ pr_debug("magic: %08x\n", be32_to_cpu(blob->magic));
+ pr_debug("size: %08x\n", be32_to_cpu(blob->totalsize));
+ pr_debug("version: %08x\n", be32_to_cpu(blob->version));
+
+ if (be32_to_cpu(blob->magic) != OF_DT_HEADER) {
+ pr_err("Invalid device tree blob header\n");
+ return;
+ }
+
+ /* First pass, scan for size */
+ start = ((unsigned long)blob) +
+ be32_to_cpu(blob->off_dt_struct);
+ size = unflatten_dt_node(blob, 0, &start, NULL, NULL, 0);
+ size = (size | 3) + 1;
+
+ pr_debug(" size is %lx, allocating...\n", size);
+
+ /* Allocate memory for the expanded device tree */
+ mem = (unsigned long)
+ dt_alloc(size + 4, __alignof__(struct device_node));
+
+ ((__be32 *)mem)[size / 4] = cpu_to_be32(0xdeadbeef);
+
+ pr_debug(" unflattening %lx...\n", mem);
+
+ /* Second pass, do actual unflattening */
+ start = ((unsigned long)blob) +
+ be32_to_cpu(blob->off_dt_struct);
+ unflatten_dt_node(blob, mem, &start, NULL, &allnextp, 0);
+ if (be32_to_cpup((__be32 *)start) != OF_DT_END)
+ pr_warning("Weird tag at end of tree: %08x\n", *((u32 *)start));
+ if (be32_to_cpu(((__be32 *)mem)[size / 4]) != 0xdeadbeef)
+ pr_warning("End of tree marker overwritten: %08x\n",
+ be32_to_cpu(((__be32 *)mem)[size / 4]));
+ *allnextp = NULL;
+
+ pr_debug(" <- unflatten_device_tree()\n");
+}
+
+static void *kernel_tree_alloc(u64 size, u64 align)
+{
+ return kzalloc(size, GFP_KERNEL);
+}
+
+/**
+ * of_fdt_unflatten_tree - create tree of device_nodes from flat blob
+ *
+ * unflattens the device-tree passed by the firmware, creating the
+ * tree of struct device_node. It also fills the "name" and "type"
+ * pointers of the nodes so the normal device-tree walking functions
+ * can be used.
+ */
+void of_fdt_unflatten_tree(unsigned long *blob,
+ struct device_node **mynodes)
+{
+ struct boot_param_header *device_tree =
+ (struct boot_param_header *)blob;
+ __unflatten_device_tree(device_tree, mynodes, &kernel_tree_alloc);
+}
+EXPORT_SYMBOL_GPL(of_fdt_unflatten_tree);
+
/* Everything below here references initial_boot_params directly. */
int __initdata dt_root_addr_cells;
int __initdata dt_root_size_cells;
@@ -569,6 +659,12 @@ int __init early_init_dt_scan_chosen(unsigned long node, const char *uname,
return 1;
}
+static void *__init early_device_tree_alloc(u64 size, u64 align)
+{
+ unsigned long mem = early_init_dt_alloc_memory_arch(size, align);
+ return __va(mem);
+}
+
/**
* unflatten_device_tree - create tree of device_nodes from flat blob
*
@@ -579,62 +675,13 @@ int __init early_init_dt_scan_chosen(unsigned long node, const char *uname,
*/
void __init unflatten_device_tree(void)
{
- unsigned long start, mem, size;
- struct device_node **allnextp = &allnodes;
-
- pr_debug(" -> unflatten_device_tree()\n");
-
- if (!initial_boot_params) {
- pr_debug("No device tree pointer\n");
- return;
- }
-
- pr_debug("Unflattening device tree:\n");
- pr_debug("magic: %08x\n", be32_to_cpu(initial_boot_params->magic));
- pr_debug("size: %08x\n", be32_to_cpu(initial_boot_params->totalsize));
- pr_debug("version: %08x\n", be32_to_cpu(initial_boot_params->version));
-
- if (be32_to_cpu(initial_boot_params->magic) != OF_DT_HEADER) {
- pr_err("Invalid device tree blob header\n");
- return;
- }
-
- /* First pass, scan for size */
- start = ((unsigned long)initial_boot_params) +
- be32_to_cpu(initial_boot_params->off_dt_struct);
- size = unflatten_dt_node(initial_boot_params, 0, &start,
- NULL, NULL, 0);
- size = (size | 3) + 1;
-
- pr_debug(" size is %lx, allocating...\n", size);
-
- /* Allocate memory for the expanded device tree */
- mem = early_init_dt_alloc_memory_arch(size + 4,
- __alignof__(struct device_node));
- mem = (unsigned long) __va(mem);
-
- ((__be32 *)mem)[size / 4] = cpu_to_be32(0xdeadbeef);
-
- pr_debug(" unflattening %lx...\n", mem);
-
- /* Second pass, do actual unflattening */
- start = ((unsigned long)initial_boot_params) +
- be32_to_cpu(initial_boot_params->off_dt_struct);
- unflatten_dt_node(initial_boot_params, mem, &start,
- NULL, &allnextp, 0);
- if (be32_to_cpup((__be32 *)start) != OF_DT_END)
- pr_warning("Weird tag at end of tree: %08x\n", *((u32 *)start));
- if (be32_to_cpu(((__be32 *)mem)[size / 4]) != 0xdeadbeef)
- pr_warning("End of tree marker overwritten: %08x\n",
- be32_to_cpu(((__be32 *)mem)[size / 4]));
- *allnextp = NULL;
+ __unflatten_device_tree(initial_boot_params, &allnodes,
+ early_device_tree_alloc);
/* Get pointer to OF "/chosen" node for use everywhere */
of_chosen = of_find_node_by_path("/chosen");
if (of_chosen == NULL)
of_chosen = of_find_node_by_path("/chosen@0");
-
- pr_debug(" <- unflatten_device_tree()\n");
}
#endif /* CONFIG_EARLY_FLATTREE */
diff --git a/include/linux/of_fdt.h b/include/linux/of_fdt.h
index 70c5b73..9ce5dfd 100644
--- a/include/linux/of_fdt.h
+++ b/include/linux/of_fdt.h
@@ -68,6 +68,8 @@ extern void *of_fdt_get_property(struct boot_param_header *blob,
extern int of_fdt_is_compatible(struct boot_param_header *blob,
unsigned long node,
const char *compat);
+extern void of_fdt_unflatten_tree(unsigned long *blob,
+ struct device_node **mynodes);
/* TBD: Temporary export of fdt globals - remove when code fully merged */
extern int __initdata dt_root_addr_cells;
--
1.5.6.6
This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately.
^ permalink raw reply related
* [PATCH 2/7] arch/x86: Add support for device tree code.
From: Stephen Neuendorffer @ 2010-11-18 23:54 UTC (permalink / raw)
To: grant.likely, dirk.brandewie, devicetree-discuss, linuxppc-dev,
microblaze-uclinux
In-Reply-To: <1290124502-13125-2-git-send-email-stephen.neuendorffer@xilinx.com>
A few support device-tree related support functions that x86 didn't
have before.
Signed-off-by: Stephen Neuendorffer <stephen.neuendorffer@xilinx.com>
----
Looks like just some irq related junk left!
---
arch/x86/include/asm/irq.h | 2 ++
arch/x86/kernel/irq.c | 11 +++++++++++
2 files changed, 13 insertions(+), 0 deletions(-)
diff --git a/arch/x86/include/asm/irq.h b/arch/x86/include/asm/irq.h
index 5458380..af4e630 100644
--- a/arch/x86/include/asm/irq.h
+++ b/arch/x86/include/asm/irq.h
@@ -10,6 +10,8 @@
#include <asm/apicdef.h>
#include <asm/irq_vectors.h>
+#define irq_dispose_mapping(...)
+
static inline int irq_canonicalize(int irq)
{
return ((irq == 2) ? 9 : irq);
diff --git a/arch/x86/kernel/irq.c b/arch/x86/kernel/irq.c
index 91fd0c7..a3aaed4 100644
--- a/arch/x86/kernel/irq.c
+++ b/arch/x86/kernel/irq.c
@@ -364,3 +364,14 @@ void fixup_irqs(void)
}
}
#endif
+
+#ifdef CONFIG_OF
+#include <linux/of_irq.h>
+unsigned int irq_create_of_mapping(struct device_node *controller,
+ const u32 *intspec, unsigned int intsize)
+{
+ return intspec[0] + 1;
+}
+EXPORT_SYMBOL_GPL(irq_create_of_mapping);
+
+#endif
--
1.5.6.6
This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately.
^ permalink raw reply related
* [PATCH 1/7] fdt: Add Kconfig for EARLY_FLATTREE
From: Stephen Neuendorffer @ 2010-11-18 23:54 UTC (permalink / raw)
To: grant.likely, dirk.brandewie, devicetree-discuss, linuxppc-dev,
microblaze-uclinux
In-Reply-To: <1290124502-13125-1-git-send-email-stephen.neuendorffer@xilinx.com>
The device tree code is now in two pieces: some which can be used generically
on any platform which selects CONFIG_OF_FLATTREE, and some early which is used
at boot time on only a few architectures. This patch segregates the early
code so that only those architectures which care about it need compile it.
This also means that some of the requirements in the early code (such as
a cmd_line variable) that most architectures (e.g. X86) don't provide
can be ignored.
Signed-off-by: Stephen Neuendorffer <stephen.neuendorffer@xilinx.com>
----
Grant,
We had discussed doing something like this a loooong time ago. This (or at
least some other way of dealing with cmd_line) is
actually necessary to compile on X86. Do you still want to do it this way?
Looking at my old email, you suggested only powerpc and microblaze need this.
Is that still the case?
Conflicts:
drivers/of/fdt.c
---
arch/microblaze/Kconfig | 1 +
arch/powerpc/Kconfig | 1 +
drivers/of/Kconfig | 5 +++++
drivers/of/fdt.c | 4 ++++
4 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/arch/microblaze/Kconfig b/arch/microblaze/Kconfig
index 692fdfc..384375c 100644
--- a/arch/microblaze/Kconfig
+++ b/arch/microblaze/Kconfig
@@ -20,6 +20,7 @@ config MICROBLAZE
select TRACING_SUPPORT
select OF
select OF_FLATTREE
+ select OF_EARLY_FLATTREE
config SWAP
def_bool n
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 631e5a0..2cd7b32 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -119,6 +119,7 @@ config PPC
default y
select OF
select OF_FLATTREE
+ select OF_EARLY_FLATTREE
select HAVE_FTRACE_MCOUNT_RECORD
select HAVE_DYNAMIC_FTRACE
select HAVE_FUNCTION_TRACER
diff --git a/drivers/of/Kconfig b/drivers/of/Kconfig
index aa675eb..0199157 100644
--- a/drivers/of/Kconfig
+++ b/drivers/of/Kconfig
@@ -19,6 +19,10 @@ config OF_FLATTREE
bool
select DTC
+config OF_EARLY_FLATTREE
+ bool
+ depends on OF_FLATTREE
+
config OF_PROMTREE
bool
@@ -62,3 +66,4 @@ config OF_MDIO
OpenFirmware MDIO bus (Ethernet PHY) accessors
endmenu # OF
+
diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
index c1360e0..4d71b29 100644
--- a/drivers/of/fdt.c
+++ b/drivers/of/fdt.c
@@ -27,6 +27,8 @@ int __initdata dt_root_size_cells;
struct boot_param_header *initial_boot_params;
+#ifdef CONFIG_EARLY_FLATTREE
+
char *find_flat_dt_string(u32 offset)
{
return ((char *)initial_boot_params) +
@@ -604,3 +606,5 @@ void __init unflatten_device_tree(void)
pr_debug(" <- unflatten_device_tree()\n");
}
+
+#endif /* CONFIG_EARLY_FLATTREE */
--
1.5.6.6
This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately.
^ permalink raw reply related
* [PATCH 0/7] add of_fdt_unflatten_tree
From: Stephen Neuendorffer @ 2010-11-18 23:54 UTC (permalink / raw)
To: grant.likely, dirk.brandewie, devicetree-discuss, linuxppc-dev,
microblaze-uclinux
In-Reply-To: <1290021345-4303-1-git-send-email-stephen.neuendorffer@xilinx.com>
Currently, fdt blobs are handled solely at boot time. However,
it may be useful to parse blobs into device trees after boot time. For
instance, a PCIe device may have an FPGA which includes a device
tree. This set of patches locally refactors the existing code to enable
this.
Patch 1 and 4-7 are the interesting bits.
Patch 2 and 3 provide the ability to use this code on x86, and are provided mostly for reference.
The non-early boot code has been compile-tested and executed on X86.
Stephen Neuendorffer (7):
fdt: Add Kconfig for EARLY_FLATTREE
arch/x86: Add support for device tree code.
arch/x86: select OF and OF_FLATTREE
fdt.c: Add non-boottime device tree functions
fdt.c: Refactor unflatten_dt_node
fdt.c: Reorder unflatten_dt_node
fdt.c: Refactor unflatten_device_tree and add fdt_unflatten_tree
arch/microblaze/Kconfig | 1 +
arch/powerpc/Kconfig | 1 +
arch/x86/Kconfig | 2 +
arch/x86/include/asm/irq.h | 2 +
arch/x86/kernel/irq.c | 11 ++
drivers/of/Kconfig | 5 +
drivers/of/fdt.c | 393 ++++++++++++++++++++++++++------------------
include/linux/of_fdt.h | 13 ++
8 files changed, 272 insertions(+), 156 deletions(-)
This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately.
^ permalink raw reply
* Re: [git pull] Please pull powerpc.git merge branch
From: Michael Ellerman @ 2010-11-18 22:08 UTC (permalink / raw)
To: Michael Neuling; +Cc: linuxppc-dev list
In-Reply-To: <30983.1290116555@neuling.org>
[-- Attachment #1: Type: text/plain, Size: 1114 bytes --]
On Fri, 2010-11-19 at 08:42 +1100, Michael Neuling wrote:
> > Michael Neuling (1):
> > powerpc: Fix call to subpage_protection()
>
> Well that's annoying...
>
> Looks like the bottom of my commit got chopped as the oops message has a
> "---" in it. We lost the cc: stable@kernel.org :-(
>
> Comparing the original post to the final commit:
> http://lists.ozlabs.org/pipermail/linuxppc-dev/2010-November/087141.html
> To the final:
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=1c2c25c78740b2796c7c06640784cb6732fa4907
LOL.
> It'd be nice if we had something like this in:
> powerpc: fix debug prints to avoid ---
>
> Many commit tools assume anything below a line starting with --- is a
> comment. Since the following two prints are often used as debug
> outputs and hence in checkin comments avoid using --- in these
>
> Signed-off-by: Michael Neuling <mikey@neuling.org>
> ---
> Let the bike shedding begin!
I vote for:
-> Exception: 401 (Instruction Access) at 00000000f7937794
Because exceptions are like an arrow!
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: [PATCH v2] iSeries: Remove unused mf_getSrcHistory function and caller.
From: Jesper Juhl @ 2010-11-18 21:51 UTC (permalink / raw)
To: Michael Ellerman
Cc: Stephen Rothwell, Paul Mackerras, linuxppc-dev, linux-kernel
In-Reply-To: <1290117470.29105.9.camel@concordia>
On Fri, 19 Nov 2010, Michael Ellerman wrote:
> On Thu, 2010-11-18 at 20:45 +0100, Jesper Juhl wrote:
> > On Fri, 5 Nov 2010, Jesper Juhl wrote:
> > >
> > > static int mf_src_proc_open(struct inode *inode, struct file *file)
>
> > PING.
> >
> > Is this going to get merged somewhere or is there a problem?
>
> Yes, no.
>
> It won't get lost:
> http://patchwork.ozlabs.org/patch/70201/
>
Ok. Thank you for that bit of information. That was one place that I had
no knowledge about what-so-ever, so I didn't look.
I will now rest happily in the knowledge that the patch is in good hands.
Thanks.
--
Jesper Juhl <jj@chaosbits.net> http://www.chaosbits.net/
Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please.
^ permalink raw reply
* Re: [PATCH v2] iSeries: Remove unused mf_getSrcHistory function and caller.
From: Michael Ellerman @ 2010-11-18 21:57 UTC (permalink / raw)
To: Jesper Juhl; +Cc: Stephen Rothwell, Paul Mackerras, linuxppc-dev, linux-kernel
In-Reply-To: <alpine.LNX.2.00.1011182044490.3651@swampdragon.chaosbits.net>
[-- Attachment #1: Type: text/plain, Size: 345 bytes --]
On Thu, 2010-11-18 at 20:45 +0100, Jesper Juhl wrote:
> On Fri, 5 Nov 2010, Jesper Juhl wrote:
> >
> > static int mf_src_proc_open(struct inode *inode, struct file *file)
> PING.
>
> Is this going to get merged somewhere or is there a problem?
Yes, no.
It won't get lost:
http://patchwork.ozlabs.org/patch/70201/
cheers
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: [PATCH] powerpc: fix call to subpage_protection()
From: Michael Ellerman @ 2010-11-18 21:53 UTC (permalink / raw)
To: Michael Neuling; +Cc: Jim Keniston, linuxppc-dev, David Gibson
In-Reply-To: <25179.1290111882@neuling.org>
[-- Attachment #1: Type: text/plain, Size: 1504 bytes --]
On Fri, 2010-11-19 at 07:24 +1100, Michael Neuling wrote:
> > On Thu, 2010-11-18 at 13:32 +1100, Michael Neuling wrote:
> > > In:=20
> > > powerpc/mm: Fix pgtable cache cleanup with CONFIG_PPC_SUBPAGE_PROT
> > > commit d28513bc7f675d28b479db666d572e078ecf182d
> > > Author: David Gibson <david@gibson.dropbear.id.au>
> > >=20
> > > subpage_protection() was changed to to take an mm rather a pgdir but it
> > > didn't change calling site in hashpage_preload(). The change wasn't
> > > noticed at compile time since hashpage_preload() used a void* as the
> > > parameter to subpage_protection().
> > ...=20
> > >=20
> > > diff --git a/arch/powerpc/mm/hash_utils_64.c b/arch/powerpc/mm/hash_utils=
> > _64.c
> > > index 83f534d..5e95844 100644
> > > --- a/arch/powerpc/mm/hash_utils_64.c
> > > +++ b/arch/powerpc/mm/hash_utils_64.c
> > > @@ -1123,7 +1123,7 @@ void hash_preload(struct mm_struct *mm, unsigned lo=
> > ng ea,
> > > else
> > > #endif /* CONFIG_PPC_HAS_HASH_64K */
> > > rc =3D __hash_page_4K(ea, access, vsid, ptep, trap, local, ssiz
> e,
> > > - subpage_protection(pgdir, ea));
> > > + subpage_protection(mm, ea));
> >
> > Type checking is fun :)
> >
> > This is stable material no?
>
> Yes. In the bit you snipped was a:
>
> cc: stable@kernel.org (only 2.6.33 and newer)
Oh right, I thought you actually had to send it to them :D
> Fortunately it's not in 2.6.32 so the bug missed the distros.
Phew.
cheers
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: [git pull] Please pull powerpc.git merge branch
From: Michael Neuling @ 2010-11-18 21:42 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev list
In-Reply-To: <1290059208.32570.3.camel@pasglop>
> Michael Neuling (1):
> powerpc: Fix call to subpage_protection()
Well that's annoying...
Looks like the bottom of my commit got chopped as the oops message has a
"---" in it. We lost the cc: stable@kernel.org :-(
Comparing the original post to the final commit:
http://lists.ozlabs.org/pipermail/linuxppc-dev/2010-November/087141.html
To the final:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=1c2c25c78740b2796c7c06640784cb6732fa4907
It'd be nice if we had something like this in:
powerpc: fix debug prints to avoid ---
Many commit tools assume anything below a line starting with --- is a
comment. Since the following two prints are often used as debug
outputs and hence in checkin comments avoid using --- in these
Signed-off-by: Michael Neuling <mikey@neuling.org>
---
Let the bike shedding begin!
arch/powerpc/kernel/process.c | 2 +-
arch/powerpc/xmon/xmon.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
Index: linux-2.6-ozlabs/arch/powerpc/kernel/process.c
===================================================================
--- linux-2.6-ozlabs.orig/arch/powerpc/kernel/process.c
+++ linux-2.6-ozlabs/arch/powerpc/kernel/process.c
@@ -1167,7 +1167,7 @@
struct pt_regs *regs = (struct pt_regs *)
(sp + STACK_FRAME_OVERHEAD);
lr = regs->link;
- printk("--- Exception: %lx at %pS\n LR = %pS\n",
+ printk("=== Exception: %lx at %pS\n LR = %pS\n",
regs->trap, (void *)regs->nip, (void *)lr);
firstframe = 1;
}
Index: linux-2.6-ozlabs/arch/powerpc/xmon/xmon.c
===================================================================
--- linux-2.6-ozlabs.orig/arch/powerpc/xmon/xmon.c
+++ linux-2.6-ozlabs/arch/powerpc/xmon/xmon.c
@@ -1363,7 +1363,7 @@
sp + REGS_OFFSET);
break;
}
- printf("--- Exception: %lx %s at ", regs.trap,
+ printf("=== Exception: %lx %s at ", regs.trap,
getvecname(TRAP(®s)));
pc = regs.nip;
lr = regs.link;
^ permalink raw reply
* Re: application needs fast access to physical memory
From: Scott Wood @ 2010-11-18 20:48 UTC (permalink / raw)
To: steven.lin; +Cc: linuxppc-dev, David Gibson
In-Reply-To: <OF40046BB1.06061608-ON882577DF.00711C8B-862577DF.00721D60@notes.teradyne.com>
On Thu, 18 Nov 2010 14:46:16 -0600
<steven.lin@teradyne.com> wrote:
> Hello Scott,
>
> Do you know whether this patch is necessary if I were to use alloc_bootmem
> () (to set aside a region of contiguous physical memory) instead of the
> kernel parameter "mem=256"?
It should not be needed in that case.
-Scott
^ permalink raw reply
* Re: application needs fast access to physical memory
From: steven.lin @ 2010-11-18 20:46 UTC (permalink / raw)
To: Scott Wood; +Cc: steven.lin, linuxppc-dev, David Gibson
In-Reply-To: <20101118133549.1c6d2cc3@udp111988uds.am.freescale.net>
[-- Attachment #1.1: Type: text/plain, Size: 3437 bytes --]
Hello Scott,
Do you know whether this patch is necessary if I were to use alloc_bootmem
() (to set aside a region of contiguous physical memory) instead of the
kernel parameter "mem=256"?
-Steve Lin
Scott Wood
<scottwood@freesc
ale.com> To
<steven.lin@teradyne.com>
11/18/2010 01:35 cc
PM David Gibson
<david@gibson.dropbear.id.au>,
Michael Ellerman
<michael@ellerman.id.au>,
<linuxppc-dev@lists.ozlabs.org>
Subject
Re: application needs fast access
to physical memory
On Thu, 18 Nov 2010 10:55:21 -0600
<steven.lin@teradyne.com> wrote:
> Thanks for the replies.
>
> In the Linux Device Drivers book regarding mmap(), it states:
>
> Mapping a device means associating a range of user-space addresses to
> device memory.
> Whenever the program reads or writes in the assigned address range, it
> is actually
> accessing the device. In the X server example, using mmap allows quick
> and easy
> access to the video card’s memory. For a performance-critical
> application like this,
> direct access makes a large difference.
>
> For whatever reason, mmap() is definitely not quick and does not appear
to
> be a direct access to device memory. After the application completes a
> large write into physical memory (via the pointer returned from mmap()),
> the application performs an ioctl() to query whether the data actually
> arrived into the memory region. It seems to take some time before the
> associated kernel module actually "sees" the data in the physical memory
> region.
>
> There's a few things I should say about this memory region. There's a
total
> of 512 MB of physical memory. U-Boot passes "mem=256M" as a kernel
> parameter to tell Linux to only directly manage the lower 256 MB. The
> special region of physical memory that the application is trying to
access
> is the upper 256 MB of memory not directly managed by Linux. The mmap()
> call from the application is:
> *memptr = (void *) mmap( NULL, size, PROT_READ | PROT_WRITE,
MAP_SHARED,
> _fdTerAlloc, (off_t) 0x10000000);
Try this patch:
http://patchwork.ozlabs.org/patch/68246/
-Scott
[-- Attachment #1.2: Type: text/html, Size: 4936 bytes --]
[-- Attachment #2: graycol.gif --]
[-- Type: image/gif, Size: 105 bytes --]
[-- Attachment #3: pic02222.gif --]
[-- Type: image/gif, Size: 1255 bytes --]
[-- Attachment #4: ecblank.gif --]
[-- Type: image/gif, Size: 45 bytes --]
^ permalink raw reply
* Re: [PATCH] powerpc: fix call to subpage_protection()
From: Michael Neuling @ 2010-11-18 20:24 UTC (permalink / raw)
To: michael; +Cc: Jim Keniston, linuxppc-dev, David Gibson
In-Reply-To: <1290082861.22575.6.camel@concordia>
> On Thu, 2010-11-18 at 13:32 +1100, Michael Neuling wrote:
> > In:=20
> > powerpc/mm: Fix pgtable cache cleanup with CONFIG_PPC_SUBPAGE_PROT
> > commit d28513bc7f675d28b479db666d572e078ecf182d
> > Author: David Gibson <david@gibson.dropbear.id.au>
> >=20
> > subpage_protection() was changed to to take an mm rather a pgdir but it
> > didn't change calling site in hashpage_preload(). The change wasn't
> > noticed at compile time since hashpage_preload() used a void* as the
> > parameter to subpage_protection().
> ...=20
> >=20
> > diff --git a/arch/powerpc/mm/hash_utils_64.c b/arch/powerpc/mm/hash_utils=
> _64.c
> > index 83f534d..5e95844 100644
> > --- a/arch/powerpc/mm/hash_utils_64.c
> > +++ b/arch/powerpc/mm/hash_utils_64.c
> > @@ -1123,7 +1123,7 @@ void hash_preload(struct mm_struct *mm, unsigned lo=
> ng ea,
> > else
> > #endif /* CONFIG_PPC_HAS_HASH_64K */
> > rc =3D __hash_page_4K(ea, access, vsid, ptep, trap, local, ssiz
e,
> > - subpage_protection(pgdir, ea));
> > + subpage_protection(mm, ea));
>
> Type checking is fun :)
>
> This is stable material no?
Yes. In the bit you snipped was a:
cc: stable@kernel.org (only 2.6.33 and newer)
Fortunately it's not in 2.6.32 so the bug missed the distros.
Mikey
^ permalink raw reply
* Re: [PATCH] powerpc: fix call to subpage_protection()
From: Benjamin Herrenschmidt @ 2010-11-18 20:06 UTC (permalink / raw)
To: Jim Keniston; +Cc: Michael Neuling, linuxppc-dev, David Gibson
In-Reply-To: <1290104610.3067.32.camel@localhost>
On Thu, 2010-11-18 at 10:23 -0800, Jim Keniston wrote:
> FWIW, this failure isn't an obstacle for me. I'm in no way attached to
> my legacy configuration; pseries_defconfig is fine for me. On the other
> hand, I can continue testing fixes, and/or make my system available to
> other IBMers when I'm not using it, if you want to continue to pursue
> this problem.
>
> Thank
>From the look of it your "legacy" config is lacking the necessary
storage drivers...
Ben.
> .
> Jim
>
> >
> >
> > diff --git a/arch/powerpc/mm/hash_utils_64.c b/arch/powerpc/mm/hash_utils_64.c
> > index 83f534d..5e95844 100644
> > --- a/arch/powerpc/mm/hash_utils_64.c
> > +++ b/arch/powerpc/mm/hash_utils_64.c
> > @@ -1123,7 +1123,7 @@ void hash_preload(struct mm_struct *mm, unsigned long ea,
> > else
> > #endif /* CONFIG_PPC_HAS_HASH_64K */
> > rc = __hash_page_4K(ea, access, vsid, ptep, trap, local, ssize,
> > - subpage_protection(pgdir, ea));
> > + subpage_protection(mm, ea));
> >
> > /* Dump some info in case of hash insertion failure, they should
> > * never happen so it is really useful to know if/when they do
> >
> >
>
^ permalink raw reply
* Re: [PATCH v2] iSeries: Remove unused mf_getSrcHistory function and caller.
From: Jesper Juhl @ 2010-11-18 19:45 UTC (permalink / raw)
To: Michael Ellerman
Cc: Stephen Rothwell, Paul Mackerras, linuxppc-dev, linux-kernel
In-Reply-To: <alpine.LNX.2.00.1011050026220.16015@swampdragon.chaosbits.net>
On Fri, 5 Nov 2010, Jesper Juhl wrote:
> On Tue, 2 Nov 2010, Michael Ellerman wrote:
>
> > On Mon, 2010-11-01 at 22:20 +0100, Jesper Juhl wrote:
> > > Hi Stephen,
> > >
> > > On Tue, 2 Nov 2010, Stephen Rothwell wrote:
> > >
> > > > On Mon, 1 Nov 2010 21:06:23 +0100 (CET) Jesper Juhl <jj@chaosbits.net> wrote:
> > > > >
> > > > > Remove unused function 'mf_getSrcHistory' (that will never be used ever
> > > > > according to Stephen Rothwell).
> > > > >
> > > > > Signed-off-by: Jesper Juhl <jj@chaosbits.net>
> > > >
> > > > Acked-by: Stephen Rothwell <sfr@canb.auug.org.au>
> > > >
> > >
> > > Ok, so if you are the (unofficial) iSeries maintainer and you don't merge
> > > the patch somewhere that'll eventually go up-stream, but just ACK it
> > > (thank you for that btw), then where do I send it to get it merged?
> >
> > Here. ie. linuxppc-dev.
> >
> > But, while you're removing it you should remove the #if 0'ed callsite as
> > well, see mf_src_proc_show() in that file. :)
> >
> Done. See patch below.
>
>
> Remove unused function 'mf_getSrcHistory' (that will never be used
> ever according to Stephen Rothwell) and also remove most of (under 'if
> 0') code from mf_src_proc_show() where the function was called.
>
> Signed-off-by: Jesper Juhl <jj@chaosbits.net>
> ---
> mf.c | 62
> --------------------------------------------------------------
> 1 file changed, 62 deletions(-)
>
> diff --git a/arch/powerpc/platforms/iseries/mf.c b/arch/powerpc/platforms/iseries/mf.c
> index 42d0a88..b5e026b 100644
> --- a/arch/powerpc/platforms/iseries/mf.c
> +++ b/arch/powerpc/platforms/iseries/mf.c
> @@ -1045,71 +1045,9 @@ static const struct file_operations mf_side_proc_fops = {
> .write = mf_side_proc_write,
> };
>
> -#if 0
> -static void mf_getSrcHistory(char *buffer, int size)
> -{
> - struct IplTypeReturnStuff return_stuff;
> - struct pending_event *ev = new_pending_event();
> - int rc = 0;
> - char *pages[4];
> -
> - pages[0] = kmalloc(4096, GFP_ATOMIC);
> - pages[1] = kmalloc(4096, GFP_ATOMIC);
> - pages[2] = kmalloc(4096, GFP_ATOMIC);
> - pages[3] = kmalloc(4096, GFP_ATOMIC);
> - if ((ev == NULL) || (pages[0] == NULL) || (pages[1] == NULL)
> - || (pages[2] == NULL) || (pages[3] == NULL))
> - return -ENOMEM;
> -
> - return_stuff.xType = 0;
> - return_stuff.xRc = 0;
> - return_stuff.xDone = 0;
> - ev->event.hp_lp_event.xSubtype = 6;
> - ev->event.hp_lp_event.x.xSubtypeData =
> - subtype_data('M', 'F', 'V', 'I');
> - ev->event.data.vsp_cmd.xEvent = &return_stuff;
> - ev->event.data.vsp_cmd.cmd = 4;
> - ev->event.data.vsp_cmd.lp_index = HvLpConfig_getLpIndex();
> - ev->event.data.vsp_cmd.result_code = 0xFF;
> - ev->event.data.vsp_cmd.reserved = 0;
> - ev->event.data.vsp_cmd.sub_data.page[0] = iseries_hv_addr(pages[0]);
> - ev->event.data.vsp_cmd.sub_data.page[1] = iseries_hv_addr(pages[1]);
> - ev->event.data.vsp_cmd.sub_data.page[2] = iseries_hv_addr(pages[2]);
> - ev->event.data.vsp_cmd.sub_data.page[3] = iseries_hv_addr(pages[3]);
> - mb();
> - if (signal_event(ev) != 0)
> - return;
> -
> - while (return_stuff.xDone != 1)
> - udelay(10);
> - if (return_stuff.xRc == 0)
> - memcpy(buffer, pages[0], size);
> - kfree(pages[0]);
> - kfree(pages[1]);
> - kfree(pages[2]);
> - kfree(pages[3]);
> -}
> -#endif
> -
> static int mf_src_proc_show(struct seq_file *m, void *v)
> {
> -#if 0
> - int len;
> -
> - mf_getSrcHistory(page, count);
> - len = count;
> - len -= off;
> - if (len < count) {
> - *eof = 1;
> - if (len <= 0)
> - return 0;
> - } else
> - len = count;
> - *start = page + off;
> - return len;
> -#else
> return 0;
> -#endif
> }
>
> static int mf_src_proc_open(struct inode *inode, struct file *file)
>
>
>
>
PING.
Is this going to get merged somewhere or is there a problem?
--
Jesper Juhl <jj@chaosbits.net> http://www.chaosbits.net/
Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please.
^ permalink raw reply
* Re: application needs fast access to physical memory
From: Scott Wood @ 2010-11-18 19:35 UTC (permalink / raw)
To: steven.lin; +Cc: linuxppc-dev, David Gibson
In-Reply-To: <OF313AFE4A.0F7F91F0-ON882577DF.0057B647-862577DF.005CF920@notes.teradyne.com>
On Thu, 18 Nov 2010 10:55:21 -0600
<steven.lin@teradyne.com> wrote:
> Thanks for the replies.
>=20
> In the Linux Device Drivers book regarding mmap(), it states:
>=20
> Mapping a device means associating a range of user-space addresses to
> device memory.
> Whenever the program reads or writes in the assigned address range, it
> is actually
> accessing the device. In the X server example, using mmap allows quick
> and easy
> access to the video card=E2=80=99s memory. For a performance-critical
> application like this,
> direct access makes a large difference.
>=20
> For whatever reason, mmap() is definitely not quick and does not appear to
> be a direct access to device memory. After the application completes a
> large write into physical memory (via the pointer returned from mmap()),
> the application performs an ioctl() to query whether the data actually
> arrived into the memory region. It seems to take some time before the
> associated kernel module actually "sees" the data in the physical memory
> region.
>=20
> There's a few things I should say about this memory region. There's a tot=
al
> of 512 MB of physical memory. U-Boot passes "mem=3D256M" as a kernel
> parameter to tell Linux to only directly manage the lower 256 MB. The
> special region of physical memory that the application is trying to access
> is the upper 256 MB of memory not directly managed by Linux. The mmap()
> call from the application is:
> *memptr =3D (void *) mmap( NULL, size, PROT_READ | PROT_WRITE, MAP_SHA=
RED,
> _fdTerAlloc, (off_t) 0x10000000);
Try this patch:
http://patchwork.ozlabs.org/patch/68246/
-Scott
^ permalink raw reply
* Re: Gianfar TCP checksumming broken in 2.6.35+
From: David Miller @ 2010-11-18 19:34 UTC (permalink / raw)
To: mlcreech; +Cc: linuxppc-dev
In-Reply-To: <AANLkTi=fZnj94761L_=1DpPAErVG8EHESObtd+d5xJfK@mail.gmail.com>
From: "Matthew L. Creech" <mlcreech@gmail.com>
Date: Thu, 18 Nov 2010 14:31:46 -0500
> On Thu, Nov 18, 2010 at 12:06 PM, David Miller <davem@davemloft.net> =
wrote:
>>
>> Can someone please follow up Matthew to get this bug resolved? =A0It=
has
>> been sitting around for a long time.
>>
>> I suspect the gianfar driver, for these chip revisions, will need to=
>> do a software checksum when the offset matches the criteria mentione=
d
>> in the errata above.
>>
> =
> I added a patch for this which fixes our affected systems; however, I=
> don't know if this is a good way to perform checksum offloading, I
> just kind of dug around until I found a function that seemed like it
> worked. :) Patch against 2.6.36 is below for reference.
It looks fine except I would limit the software checksum to the
exact conditions listed in the errate.
Otherwise this is going to hurt performance and cpu utilization
quite a bit.
^ permalink raw reply
* Re: Gianfar TCP checksumming broken in 2.6.35+
From: Matthew L. Creech @ 2010-11-18 19:31 UTC (permalink / raw)
To: David Miller; +Cc: linuxppc-dev
In-Reply-To: <20101118.090615.71123752.davem@davemloft.net>
On Thu, Nov 18, 2010 at 12:06 PM, David Miller <davem@davemloft.net> wrote:
>
> Can someone please follow up Matthew to get this bug resolved? =A0It has
> been sitting around for a long time.
>
> I suspect the gianfar driver, for these chip revisions, will need to
> do a software checksum when the offset matches the criteria mentioned
> in the errata above.
>
I added a patch for this which fixes our affected systems; however, I
don't know if this is a good way to perform checksum offloading, I
just kind of dug around until I found a function that seemed like it
worked. :) Patch against 2.6.36 is below for reference.
---
gianfar.c | 21 +++++++++++++++++++--
gianfar.h | 1 +
2 files changed, 20 insertions(+), 2 deletions(-)
diff -purN orig/drivers/net/gianfar.c linux-2.6.36/drivers/net/gianfar.c
--- orig/drivers/net/gianfar.c 2010-11-03 15:10:29.287140651 -0400
+++ linux-2.6.36/drivers/net/gianfar.c 2010-11-03 16:01:03.754321896 -0400
@@ -937,6 +937,10 @@ static void gfar_detect_errata(struct gf
unsigned int mod =3D (svr >> 16) & 0xfff6; /* w/o E suffix */
unsigned int rev =3D svr & 0xffff;
+ /* MPC8313 Rev < 2.0 */
+ if (pvr =3D=3D 0x80850010 && mod =3D=3D 0x80b0 && rev < 0x0020)
+ priv->errata |=3D GFAR_ERRATA_12;
+
/* MPC8313 Rev 2.0 and higher; All MPC837x */
if ((pvr =3D=3D 0x80850010 && mod =3D=3D 0x80b0 && rev >=3D 0x0020) ||
(pvr =3D=3D 0x80861010 && (mod & 0xfff9) =3D=3D 0x80c0))
@@ -1984,7 +1988,8 @@ static inline struct txfcb *gfar_add_fcb
return fcb;
}
-static inline void gfar_tx_checksum(struct sk_buff *skb, struct txfcb *fcb=
)
+static inline void gfar_tx_checksum(struct sk_buff *skb, struct txfcb *fcb=
,
+ int has_csum_bug)
{
u8 flags =3D 0;
@@ -1994,6 +1999,17 @@ static inline void gfar_tx_checksum(stru
*/
flags =3D TXFCB_DEFAULT;
+ /* If using old-rev silicon, the alignment of the TXFCB may be off,
+ * causing TCP checksumming to fail (errata eTSEC12). In that case,
+ * we compute the checksum manually.
+ */
+ if (has_csum_bug) {
+ /* Disable handling of TCP/UDP header (checksumming) */
+ flags &=3D ~TXFCB_TUP;
+ /* Manually add checksum */
+ skb_checksum_help(skb);
+ }
+
/* Tell the controller what the protocol is */
/* And provide the already calculated phcs */
if (ip_hdr(skb)->protocol =3D=3D IPPROTO_UDP) {
@@ -2159,7 +2175,8 @@ static int gfar_start_xmit(struct sk_buf
if (CHECKSUM_PARTIAL =3D=3D skb->ip_summed) {
fcb =3D gfar_add_fcb(skb);
lstatus |=3D BD_LFLAG(TXBD_TOE);
- gfar_tx_checksum(skb, fcb);
+ gfar_tx_checksum(skb, fcb,
+ gfar_has_errata(priv, GFAR_ERRATA_12));
}
if (priv->vlgrp && vlan_tx_tag_present(skb)) {
diff -purN orig/drivers/net/gianfar.h linux-2.6.36/drivers/net/gianfar.h
--- orig/drivers/net/gianfar.h 2010-11-03 15:10:29.257142194 -0400
+++ linux-2.6.36/drivers/net/gianfar.h 2010-11-03 15:48:10.117134959 -0400
@@ -1029,6 +1029,7 @@ enum gfar_errata {
GFAR_ERRATA_74 =3D 0x01,
GFAR_ERRATA_76 =3D 0x02,
GFAR_ERRATA_A002 =3D 0x04,
+ GFAR_ERRATA_12 =3D 0x08,
};
/* Struct stolen almost completely (and shamelessly) from the FCC enet sou=
rce
--=20
Matthew L. Creech
^ permalink raw reply
* [PATCH] powerpc: minor cleanups for machdep.h
From: Sonny Rao @ 2010-11-18 10:39 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Sonny Rao, Paul Mackerras, linux-kernel, Milton Miller
remove stale declaration of setup_pci_ptrs, aparently from ppc before 2.4.0
remove #ifdef around struct existance delcaration
fix spelling of linear
Signed-off-by: Milton Miller <miltonm@bga.com>
Signed-off-by: Sonny Rao <sonnyrao@linux.vnet.ibm.com>
---
arch/powerpc/include/asm/machdep.h | 6 +-----
1 files changed, 1 insertions(+), 5 deletions(-)
diff --git a/arch/powerpc/include/asm/machdep.h b/arch/powerpc/include/asm/machdep.h
index d045b01..8433d36 100644
--- a/arch/powerpc/include/asm/machdep.h
+++ b/arch/powerpc/include/asm/machdep.h
@@ -27,9 +27,7 @@ struct iommu_table;
struct rtc_time;
struct file;
struct pci_controller;
-#ifdef CONFIG_KEXEC
struct kimage;
-#endif
#ifdef CONFIG_SMP
struct smp_ops_t {
@@ -72,7 +70,7 @@ struct machdep_calls {
int psize, int ssize);
void (*flush_hash_range)(unsigned long number, int local);
- /* special for kexec, to be called in real mode, linar mapping is
+ /* special for kexec, to be called in real mode, linear mapping is
* destroyed as well */
void (*hpte_clear_all)(void);
@@ -324,8 +322,6 @@ extern sys_ctrler_t sys_ctrler;
#endif /* CONFIG_PPC_PMAC */
-extern void setup_pci_ptrs(void);
-
#ifdef CONFIG_SMP
/* Poor default implementations */
extern void __devinit smp_generic_give_timebase(void);
--
1.5.6.5
^ permalink raw reply related
* [PATCH] Powerpc: separate CONFIG_RELOCATABLE from CONFIG_CRASHDUMP in boot code
From: Sonny Rao @ 2010-11-18 10:35 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Sonny Rao, Paul Mackerras, linux-kernel, Milton Miller
Fix head_64.S so that we can build a relocatable kernel
that isn't necessarily a crash-dump kernel
Signed-off-by: Milton Miller <miltonm@bga.com>
Signed-off-by: Sonny Rao <sonnyrao@linux.vnet.ibm.com>
---
arch/powerpc/kernel/head_64.S | 6 ++----
1 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/kernel/head_64.S b/arch/powerpc/kernel/head_64.S
index f0dd577..53b098f 100644
--- a/arch/powerpc/kernel/head_64.S
+++ b/arch/powerpc/kernel/head_64.S
@@ -96,7 +96,7 @@ __secondary_hold_acknowledge:
.llong hvReleaseData-KERNELBASE
#endif /* CONFIG_PPC_ISERIES */
-#ifdef CONFIG_CRASH_DUMP
+#ifdef CONFIG_RELOCATABLE
/* This flag is set to 1 by a loader if the kernel should run
* at the loaded address instead of the linked address. This
* is used by kexec-tools to keep the the kdump kernel in the
@@ -384,12 +384,10 @@ _STATIC(__after_prom_start)
/* process relocations for the final address of the kernel */
lis r25,PAGE_OFFSET@highest /* compute virtual base of kernel */
sldi r25,r25,32
-#ifdef CONFIG_CRASH_DUMP
lwz r7,__run_at_load-_stext(r26)
- cmplwi cr0,r7,1 /* kdump kernel ? - stay where we are */
+ cmplwi cr0,r7,1 /* flagged to stay where we are ? */
bne 1f
add r25,r25,r26
-#endif
1: mr r3,r25
bl .relocate
#endif
--
1.5.6.5
^ permalink raw reply related
* Re: [PATCH] powerpc: fix call to subpage_protection()
From: Jim Keniston @ 2010-11-18 18:23 UTC (permalink / raw)
To: Michael Neuling; +Cc: linuxppc-dev, David Gibson
In-Reply-To: <13149.1290047579@neuling.org>
[-- Attachment #1: Type: text/plain, Size: 2938 bytes --]
On Thu, 2010-11-18 at 13:32 +1100, Michael Neuling wrote:
> In:
> powerpc/mm: Fix pgtable cache cleanup with CONFIG_PPC_SUBPAGE_PROT
> commit d28513bc7f675d28b479db666d572e078ecf182d
> Author: David Gibson <david@gibson.dropbear.id.au>
>
> subpage_protection() was changed to to take an mm rather a pgdir but it
> didn't change calling site in hashpage_preload(). The change wasn't
> noticed at compile time since hashpage_preload() used a void* as the
> parameter to subpage_protection().
>
> This is obviously wrong and can trigger the following crash when
> CONFIG_SLAB, CONFIG_DEBUG_SLAB, CONFIG_PPC_64K_PAGES
> CONFIG_PPC_SUBPAGE_PROT are enabled.
>
...
>
> The following changes this subpage_protection() call.
>
> Reported-by: Jim Keniston <jkenisto@linux.vnet.ibm.com>
> Signed-off-by: Michael Neuling <mikey@neuling.org>
> Tested-by: Jim Keniston <jkenisto@linux.vnet.ibm.com>
> cc: David Gibson <david@gibson.dropbear.id.au>
> cc: stable@kernel.org (only 2.6.33 and newer)
> ---
> > It boots fine with pseries_defconfig.
> >
> > Attached is the config file that I've been using, which is probably
> > descended over many generations of kernels from some config file in my
> > machine's distant past. (Enable DEBUG_SLAB or DEBUG_PAGEALLOC and it
> > will fail to boot.) After I run 'make menuconfig' starting from
> > pseries_defconfig...
> > $ diff config_ok .config | wc -l
> > 2052
>
> I narrowed this down to adding the following on pseries_defconfig:
> +CONFIG_SLAB=y
> +CONFIG_PPC_64K_PAGES=y
> +CONFIG_PPC_SUBPAGE_PROT=y
> +CONFIG_DEBUG_SLAB=y
> To reproduce the fail.
I have indeed verified that when I apply those config changes atop
pseries_defconfig, the resulting kernel fails to boot on my Power 5
system without this fix, and boots correctly with this fix. So the
Tested-by line is correct.
Unfortunately, this fix doesn't enable my legacy configuration to boot
with CONFIG_SLAB=y. It still fails in the same way -- console output
attached.
FWIW, this failure isn't an obstacle for me. I'm in no way attached to
my legacy configuration; pseries_defconfig is fine for me. On the other
hand, I can continue testing fixes, and/or make my system available to
other IBMers when I'm not using it, if you want to continue to pursue
this problem.
Thanks.
Jim
>
>
> diff --git a/arch/powerpc/mm/hash_utils_64.c b/arch/powerpc/mm/hash_utils_64.c
> index 83f534d..5e95844 100644
> --- a/arch/powerpc/mm/hash_utils_64.c
> +++ b/arch/powerpc/mm/hash_utils_64.c
> @@ -1123,7 +1123,7 @@ void hash_preload(struct mm_struct *mm, unsigned long ea,
> else
> #endif /* CONFIG_PPC_HAS_HASH_64K */
> rc = __hash_page_4K(ea, access, vsid, ptep, trap, local, ssize,
> - subpage_protection(pgdir, ea));
> + subpage_protection(mm, ea));
>
> /* Dump some info in case of hash insertion failure, they should
> * never happen so it is really useful to know if/when they do
>
>
[-- Attachment #2: linus-oops6 --]
[-- Type: text/plain, Size: 8783 bytes --]
This is with Michael Neuling's subpage_protection fix, using my legacy
.config DEBUG_SLAB configured.
boot: linus
Using 0084e28a bytes for initrd buffer
Please wait, loading kernel...
Allocated 00f00000 bytes for kernel @ 01e00000
Elf64 kernel loaded...
Loading ramdisk...
ramdisk loaded 0084e28a @ 02d00000
OF stdout device is: /vdevice/vty@30000000
Preparing to boot Linux version 2.6.37-rc2-5-ppc64 (jimk@elm3b90) (gcc version 4.3.2 [gcc-4_3-branch revision 141291] (SUSE Linux) ) #9 SMP Wed Nov 17 18:17:23 PST 2010
Max number of cores passed to firmware: 512 (NR_CPUS = 1024)
Calling ibm,client-architecture-support... not implemented
command line: root=/dev/disk/by-id/scsi-SIBM_ST373453LC_3HW1CQ1400007445Q2A4-part3 quiet profile=2 sysrq=1 insmod=sym53c8xx insmod=ipr crashkernel=256M-:128M loglevel=8
memory layout at init:
memory_limit : 0000000000000000 (16 MB aligned)
alloc_bottom : 0000000003550000
alloc_top : 0000000008000000
alloc_top_hi : 0000000070000000
amo_top : 0000000008000000
ram_top : 0000000070000000
instantiating rtas at 0x00000000076a0000... done
boot cpu hw idx 0
starting cpu hw idx 2... done
copying OF device tree...
Building dt strings...
Building dt structure...
Device tree strings 0x0000000003560000 -> 0x000000000356129c
Device tree struct 0x0000000003570000 -> 0x0000000003580000
Calling quiesce...
returning from prom_init
Crash kernel location must be 0x2000000
Reserving 128MB of memory at 32MB for crashkernel (System RAM: 1792MB)
Phyp-dump not supported on this hardware
Allocated 655360 bytes for 1024 pacas at c000000001f30000
Using pSeries machine description
Page orders: linear mapping = 24, virtual = 12, io = 12
Found initrd at 0xc000000002d00000:0xc00000000354e28a
bootconsole [udbg0] enabled
Partition configured for 4 cpus.
CPU maps initialized for 2 threads per core
(thread shift is 1)
Freed 589824 bytes for unused pacas
Starting Linux PPC64 #9 SMP Wed Nov 17 18:17:23 PST 2010
-----------------------------------------------------
ppc64_pft_size = 0x19
physicalMemorySize = 0x70000000
htab_hash_mask = 0x3ffff
-----------------------------------------------------
Initializing cgroup subsys cpuset
Initializing cgroup subsys cpu
Linux version 2.6.37-rc2-5-ppc64 (jimk@elm3b90) (gcc version 4.3.2 [gcc-4_3-branch revision 141291] (SUSE Linux) ) #9 SMP Wed Nov 17 18:17:23 PST 2010
[boot]0012 Setup Arch
Node 0 Memory: 0x0-0x70000000
PCI host bridge /pci@800000020000002 ranges:
IO 0x000003fe00200000..0x000003fe002fffff -> 0x0000000000000000
MEM 0x0000040080000000..0x00000400bfffffff -> 0x00000000c0000000
PCI host bridge /pci@800000020000003 ranges:
IO 0x000003fe00700000..0x000003fe007fffff -> 0x0000000000000000
MEM 0x00000401c0000000..0x00000401ffffffff -> 0x00000000c0000000
EEH: PCI Enhanced I/O Error Handling Enabled
PPC64 nvram contains 7168 bytes
Using dedicated idle loop
Zone PFN ranges:
DMA 0x00000000 -> 0x00007000
Normal empty
Movable zone start PFN for each node
early_node_map[1] active PFN ranges
0: 0x00000000 -> 0x00007000
On node 0 totalpages: 28672
DMA zone: 25 pages used for memmap
DMA zone: 0 pages reserved
DMA zone: 28647 pages, LIFO batch:1
[boot]0015 Setup Done
PERCPU: Embedded 1 pages/cpu @c000000000f00000 s23424 r0 d42112 u262144
pcpu-alloc: s23424 r0 d42112 u262144 alloc=1*1048576
pcpu-alloc: [0] 0 1 2 3
Built 1 zonelists in Node order, mobility grouping on. Total pages: 28647
Policy zone: DMA
Kernel command line: root=/dev/disk/by-id/scsi-SIBM_ST373453LC_3HW1CQ1400007445Q2A4-part3 quiet profile=2 sysrq=1 insmod=sym53c8xx insmod=ipr crashkernel=256M-:128M loglevel=8
kernel profiling enabled (shift: 2)
PID hash table entries: 4096 (order: -1, 32768 bytes)
freeing bootmem node 0
Memory: 1681088k/1835008k available (8192k kernel code, 153920k reserved, 1536k data, 4447k bss, 512k init)
Hierarchical RCU implementation.
RCU-based detection of stalled CPUs is disabled.
NR_IRQS:512
[boot]0020 XICS Init
[boot]0021 XICS Done
pic: no ISA interrupt controller
time_init: decrementer frequency = 207.054000 MHz
time_init: processor frequency = 1654.344000 MHz
clocksource: timebase mult[135191e] shift[22] registered
clockevent: decrementer mult[35017dae] shift[32] cpu[0]
Console: colour dummy device 80x25
console [hvc0] enabled, bootconsole disabled
console [hvc0] enabled, bootconsole disabled
allocated 1146880 bytes of page_cgroup
please try 'cgroup_disable=memory' option if you don't want memory cgroups
pid_max: default: 32768 minimum: 301
Security Framework initialized
SELinux: Disabled at boot.
Dentry cache hash table entries: 262144 (order: 5, 2097152 bytes)
Inode-cache hash table entries: 131072 (order: 4, 1048576 bytes)
Mount-cache hash table entries: 4096
Initializing cgroup subsys ns
ns_cgroup deprecated: consider using the 'clone_children' flag without the ns_cgroup.
Initializing cgroup subsys cpuacct
Initializing cgroup subsys memory
Initializing cgroup subsys devices
Initializing cgroup subsys freezer
irq: irq 2 on host null mapped to virtual irq 16
Brought up 4 CPUs
Node 0 CPUs: 0-3
NET: Registered protocol family 16
IBM eBus Device Driver
POWER5 performance monitor hardware support registered
PCI: Probing PCI hardware
IOMMU table initialized, virtual merging enabled
pci 0000:c0:01.0: PME# supported from D0 D3hot D3cold
pci 0000:c0:01.0: PME# disabled
pci 0000:c0:01.1: PME# supported from D0 D3hot D3cold
pci 0000:c0:01.1: PME# disabled
irq: irq 115 on host null mapped to virtual irq 115
irq: irq 116 on host null mapped to virtual irq 116
pci 0001:cc:01.0: supports D1
irq: irq 150 on host null mapped to virtual irq 150
irq: irq 151 on host null mapped to virtual irq 151
PCI: Probing PCI hardware done
bio: create slab <bio-0> at 0
vgaarb: loaded
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
Switching to clocksource timebase
NET: Registered protocol family 2
IP route cache hash table entries: 16384 (order: 1, 131072 bytes)
TCP established hash table entries: 65536 (order: 4, 1048576 bytes)
TCP bind hash table entries: 65536 (order: 4, 1048576 bytes)
TCP: Hash tables configured (established 65536 bind 65536)
TCP reno registered
UDP hash table entries: 2048 (order: 0, 65536 bytes)
UDP-Lite hash table entries: 2048 (order: 0, 65536 bytes)
NET: Registered protocol family 1
PCI: CLS 128 bytes, default 128
Unpacking initramfs...
Initramfs unpacking failed: read error
RTAS daemon started
irq: irq 655360 on host null mapped to virtual irq 17
irq: irq 589825 on host null mapped to virtual irq 18
audit: initializing netlink socket (disabled)
type=2000 audit(1290100141.460:1): initialized
HugeTLB registered 16 MB page size, pre-allocated 0 pages
VFS: Disk quotas dquot_6.5.2
Dquot-cache hash table entries: 8192 (order 0, 65536 bytes)
msgmni has been set to 3284
Block layer SCSI generic (bsg) driver version 0.4 loaded (major 254)
io scheduler noop registered
io scheduler deadline registered
io scheduler cfq registered (default)
pci_hotplug: PCI Hot Plug PCI Core version: 0.5
rpaphp: RPA HOT Plug PCI Controller Driver version: 0.1
rpaphp: Slot [U787A.001.DNZ00XZ-P1-C1] registered
vio_register_driver: driver hvc_console registering
HVSI: registered 0 devices
Generic RTC Driver v1.07
Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled
pmac_zilog: 0.6 (Benjamin Herrenschmidt <benh@kernel.crashing.org>)
Uniform Multi-Platform E-IDE driver
ide-gd driver 1.18
ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
mice: PS/2 mouse device common for all mice
EDAC MC: Ver: 2.1.0 Nov 17 2010
usbcore: registered new interface driver usbhid
usbhid: USB HID core driver
TCP cubic registered
NET: Registered protocol family 15
registered taskstats version 1
md: Waiting for all devices to be available before autodetect
md: If you don't use raid, use raid=noautodetect
md: Autodetecting RAID arrays.
md: Scanned 0 and added 0 devices.
md: autorun ...
md: ... autorun DONE.
VFS: Cannot open root device "disk/by-id/scsi-SIBM_ST373453LC_3HW1CQ1400007445Q2A4-part3" or unknown-block(0,0)
Please append a correct "root=" boot option; here are the available partitions:
Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)
Call Trace:
[c00000006e78fc30] [c000000000011218] .show_stack+0x6c/0x16c (unreliable)
[c00000006e78fce0] [c00000000054b204] .panic+0x9c/0x200
[c00000006e78fd80] [c000000000781354] .mount_block_root+0x2dc/0x318
[c00000006e78fe50] [c00000000078159c] .prepare_namespace+0x184/0x1cc
[c00000006e78fee0] [c000000000780554] .kernel_init+0x2e4/0x310
[c00000006e78ff90] [c00000000002985c] .kernel_thread+0x54/0x70
Rebooting in 180 seconds..
^ permalink raw reply
* Re: Gianfar TCP checksumming broken in 2.6.35+
From: David Miller @ 2010-11-18 17:06 UTC (permalink / raw)
To: mlcreech; +Cc: linuxppc-dev
In-Reply-To: <AANLkTi=-ZAL-to4qZ0vA20L589fMQm89E9mH9WWOvX0c@mail.gmail.com>
From: "Matthew L. Creech" <mlcreech@gmail.com>
Date: Tue, 2 Nov 2010 18:29:08 -0400
> An upgrade from 2.6.34 to 2.6.35 caused networking to stop working on
> my MPC8313-based board. It turned out that TCP checksums were
> invalid, so I dug through the .35 changelog to try and isolate the
> reason. The change "tcp: Set CHECKSUM_UNNECESSARY in
> tcp_init_nondata_skb" seems to be the specific one that causes
> breakage - if I revert this one-liner, things work again:
>
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=2e8e18ef52e7dd1af0a3bd1f7d990a1d0b249586
>
> However, I also noticed that one of my boards was broken while a newer
> prototype (which is very similar, hardware-wise) was not. It turns
> out they're using 2 different revisions of silicon, so the broken
> board still has a 1.0 version microcontroller.
>
> Therefore I'm guessing (just a hunch) that the root cause of the
> problem is MPC8313 errata eTSEC12:
>
> ========
> eTSEC12: Tx IP and TCP/UDP Checksum Generation not supported for some Tx FCB
> offsets
> Description:
> If the Tx FCB (Frame Control Block) 32-byte offset is 0x19, 0x1A, 0x1B,
> 0x1C, 0x1D, 0x1E or 0x1F, IP and TCP/UDP header checksum generation do
> not function properly. The checksum value may be inserted in the wrong
> location or not inserted at all.
> IP and TCP/UDP header checksum generation is not supported in LINUX
> and other systems in which headers are prepended to pre-aligned packet
> data, or where the alignment of the Tx FCB cannot be controlled.
> This behavior applies to pseudo-header checksum insertion as well as
> checksum generation.
> Workaround:
> Align Tx FCB to a 16 or 32-byte boundary.
> If the alignment of TxFCB is not controllable, set TCTRL[TUCSEN]=0 and
> TCTRL[IPCSEN]=0 to disable IP and TCP/UDP header checksum generation.
> Fix plan:
> Fixed in Rev 2.0
> ========
>
> This appears to have been working previously, but doesn't work any
> more. I'm not familiar enough with Dave's checksum/sk_buff changes to
> figure out whether this errata is to blame, though, or how I should
> fix it if it is. Presumably there's some alignment magic needed in
> the sk_buff or gfar_add_fcb() to make sure that the microcontroller is
> happy with the FCB offset?
>
> Any tip on how I can solve this, or at least verify that this errata
> is at fault? Thanks in advance
Can someone please follow up Matthew to get this bug resolved? It has
been sitting around for a long time.
I suspect the gianfar driver, for these chip revisions, will need to
do a software checksum when the offset matches the criteria mentioned
in the errata above.
^ permalink raw reply
* Re: application needs fast access to physical memory
From: steven.lin @ 2010-11-18 16:55 UTC (permalink / raw)
To: David Gibson, Michael Ellerman; +Cc: linuxppc-dev
In-Reply-To: <20101118125425.GE7256@yookeroo>
[-- Attachment #1.1: Type: text/plain, Size: 4652 bytes --]
Thanks for the replies.
In the Linux Device Drivers book regarding mmap(), it states:
Mapping a device means associating a range of user-space addresses to
device memory.
Whenever the program reads or writes in the assigned address range, it
is actually
accessing the device. In the X server example, using mmap allows quick
and easy
access to the video card’s memory. For a performance-critical
application like this,
direct access makes a large difference.
For whatever reason, mmap() is definitely not quick and does not appear to
be a direct access to device memory. After the application completes a
large write into physical memory (via the pointer returned from mmap()),
the application performs an ioctl() to query whether the data actually
arrived into the memory region. It seems to take some time before the
associated kernel module actually "sees" the data in the physical memory
region.
There's a few things I should say about this memory region. There's a total
of 512 MB of physical memory. U-Boot passes "mem=256M" as a kernel
parameter to tell Linux to only directly manage the lower 256 MB. The
special region of physical memory that the application is trying to access
is the upper 256 MB of memory not directly managed by Linux. The mmap()
call from the application is:
*memptr = (void *) mmap( NULL, size, PROT_READ | PROT_WRITE, MAP_SHARED,
_fdTerAlloc, (off_t) 0x10000000);
On the kernel module side, the function handling the mmap() file operation
is:
static int ter_alloc_mmap( struct file *pFile, struct vm_area_struct
*vma )
{
if (remap_pfn_range(vma, vma->vm_start, vma->vm_pgoff, vma->vm_end -
vma->vm_start, vma->vm_page_prot))
return -EAGAIN;
vma->vm_ops = &ter_alloc_remap_vm_ops;
ter_alloc_vma_open(vma);
return 0;
}
-Steve Lin
David Gibson
<david@gibson.dro
pbear.id.au> To
Michael Ellerman
11/18/2010 06:54 <michael@ellerman.id.au>
AM cc
steven.lin@teradyne.com,
Steven_Lin@notes.teradyne.com,
linuxppc-dev@lists.ozlabs.org
Subject
Re: application needs fast access
to physical memory
On Thu, Nov 18, 2010 at 11:24:22PM +1100, Michael Ellerman wrote:
> On Wed, 2010-11-17 at 16:03 -0600, steven.lin@teradyne.com wrote:
> > My application needs a fast way to access a specific physical DDR
> > memory region. The application runs on an MPC8548 PowerPC which has an
> > MMU. I've tried two approaches that are typical for Linux, mmap() and
> > using a kernel module that implements read()/write() into this region
> > and I'm finding that performance is very slow for both. It's a couple
> > orders of magnitude slower than, for example, copying a large buffer
> > from one place in the application's virtual memory to another place in
> > the application's virtual memory.
>
> The mmap() version should basically run at "full speed", at least once
> you've faulted the address range in.
>
> This specific DDR region isn't specifically slow is it ? :)
The other theory that springs to mind is whatever method you're using
to access the region enabling cacheing?
--
David Gibson | I'll have my music
baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT
_the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
[attachment "signature.asc" deleted by Steven Lin/USW/Teradyne]
[-- Attachment #1.2: Type: text/html, Size: 6742 bytes --]
[-- Attachment #2: graycol.gif --]
[-- Type: image/gif, Size: 105 bytes --]
[-- Attachment #3: pic02872.gif --]
[-- Type: image/gif, Size: 1255 bytes --]
[-- Attachment #4: ecblank.gif --]
[-- Type: image/gif, Size: 45 bytes --]
^ permalink raw reply
* Re: application needs fast access to physical memory
From: David Gibson @ 2010-11-18 12:54 UTC (permalink / raw)
To: Michael Ellerman; +Cc: Steven_Lin, steven.lin, linuxppc-dev
In-Reply-To: <1290083062.22575.9.camel@concordia>
[-- Attachment #1: Type: text/plain, Size: 1192 bytes --]
On Thu, Nov 18, 2010 at 11:24:22PM +1100, Michael Ellerman wrote:
> On Wed, 2010-11-17 at 16:03 -0600, steven.lin@teradyne.com wrote:
> > My application needs a fast way to access a specific physical DDR
> > memory region. The application runs on an MPC8548 PowerPC which has an
> > MMU. I've tried two approaches that are typical for Linux, mmap() and
> > using a kernel module that implements read()/write() into this region
> > and I'm finding that performance is very slow for both. It's a couple
> > orders of magnitude slower than, for example, copying a large buffer
> > from one place in the application's virtual memory to another place in
> > the application's virtual memory.
>
> The mmap() version should basically run at "full speed", at least once
> you've faulted the address range in.
>
> This specific DDR region isn't specifically slow is it ? :)
The other theory that springs to mind is whatever method you're using
to access the region enabling cacheing?
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* RE: application needs fast access to physical memory
From: David Laight @ 2010-11-18 12:52 UTC (permalink / raw)
Cc: linuxppc-dev
In-Reply-To: <1290083062.22575.9.camel@concordia>
=20
> On Wed, 2010-11-17 at 16:03 -0600, steven.lin@teradyne.com wrote:
> > My application needs a fast way to access a specific physical DDR
> > memory region. The application runs on an MPC8548 PowerPC which has
an
> > MMU. I've tried two approaches that are typical for Linux, mmap()
and
> > using a kernel module that implements read()/write() into this
region
> > and I'm finding that performance is very slow for both. It's a
couple
> > orders of magnitude slower than, for example, copying a large buffer
> > from one place in the application's virtual memory to another place
in
> > the application's virtual memory.
>=20
> The mmap() version should basically run at "full speed", at least once
> you've faulted the address range in.
>=20
> This specific DDR region isn't specifically slow is it ? :)
Or being mapped uncached ?
David
^ permalink raw reply
* Re: application needs fast access to physical memory
From: Michael Ellerman @ 2010-11-18 12:24 UTC (permalink / raw)
To: steven.lin; +Cc: Steven_Lin, linuxppc-dev
In-Reply-To: <OFEB1252DC.D653C7C7-ON882577DE.0078DABB-862577DE.00792502@notes.teradyne.com>
[-- Attachment #1: Type: text/plain, Size: 797 bytes --]
On Wed, 2010-11-17 at 16:03 -0600, steven.lin@teradyne.com wrote:
> My application needs a fast way to access a specific physical DDR
> memory region. The application runs on an MPC8548 PowerPC which has an
> MMU. I've tried two approaches that are typical for Linux, mmap() and
> using a kernel module that implements read()/write() into this region
> and I'm finding that performance is very slow for both. It's a couple
> orders of magnitude slower than, for example, copying a large buffer
> from one place in the application's virtual memory to another place in
> the application's virtual memory.
The mmap() version should basically run at "full speed", at least once
you've faulted the address range in.
This specific DDR region isn't specifically slow is it ? :)
cheers
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 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