* [PATCH 4/8] Move allocation of cell IOMMU pad page
From: Michael Ellerman @ 2008-02-29 7:33 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <fdd3edc0f2f3d2d6cade5cd695b8080d0da95a7f.1204270367.git.michael@ellerman.id.au>
There's no need to allocate the pad page unless we're going to actually
use it - so move the allocation to where we know we're going to use it.
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
---
arch/powerpc/platforms/cell/iommu.c | 12 ++++++------
1 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/arch/powerpc/platforms/cell/iommu.c b/arch/powerpc/platforms/cell/iommu.c
index 555d264..8e57e1a 100644
--- a/arch/powerpc/platforms/cell/iommu.c
+++ b/arch/powerpc/platforms/cell/iommu.c
@@ -344,12 +344,6 @@ static void cell_iommu_setup_page_tables(struct cbe_iommu *iommu,
iommu->ptab = page_address(page);
memset(iommu->ptab, 0, ptab_size);
- /* allocate a bogus page for the end of each mapping */
- page = alloc_pages_node(iommu->nid, GFP_KERNEL, 0);
- BUG_ON(!page);
- iommu->pad_page = page_address(page);
- clear_page(iommu->pad_page);
-
/* number of pages needed for a page table */
n_pte_pages = (pages_per_segment *
sizeof(unsigned long)) >> IOMMU_PAGE_SHIFT;
@@ -463,6 +457,7 @@ cell_iommu_setup_window(struct cbe_iommu *iommu, struct device_node *np,
unsigned long pte_offset)
{
struct iommu_window *window;
+ struct page *page;
u32 ioid;
ioid = cell_iommu_get_ioid(np);
@@ -501,6 +496,11 @@ cell_iommu_setup_window(struct cbe_iommu *iommu, struct device_node *np,
* This code also assumes that we have a window that starts at 0,
* which is the case on all spider based blades.
*/
+ page = alloc_pages_node(iommu->nid, GFP_KERNEL, 0);
+ BUG_ON(!page);
+ iommu->pad_page = page_address(page);
+ clear_page(iommu->pad_page);
+
__set_bit(0, window->table.it_map);
tce_build_cell(&window->table, window->table.it_offset, 1,
(unsigned long)iommu->pad_page, DMA_TO_DEVICE);
--
1.5.2.rc1.1884.g59b20
^ permalink raw reply related
* [PATCH 3/8] Remove unused pte_offset variable
From: Michael Ellerman @ 2008-02-29 7:33 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <fdd3edc0f2f3d2d6cade5cd695b8080d0da95a7f.1204270367.git.michael@ellerman.id.au>
The cell IOMMU code no longer needs to save the pte_offset variable
separately, it is incorporated into tbl->it_offset.
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
---
arch/powerpc/platforms/cell/iommu.c | 5 +----
1 files changed, 1 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/platforms/cell/iommu.c b/arch/powerpc/platforms/cell/iommu.c
index 4e75919..555d264 100644
--- a/arch/powerpc/platforms/cell/iommu.c
+++ b/arch/powerpc/platforms/cell/iommu.c
@@ -123,7 +123,6 @@ struct iommu_window {
struct cbe_iommu *iommu;
unsigned long offset;
unsigned long size;
- unsigned long pte_offset;
unsigned int ioid;
struct iommu_table table;
};
@@ -475,13 +474,11 @@ cell_iommu_setup_window(struct cbe_iommu *iommu, struct device_node *np,
window->size = size;
window->ioid = ioid;
window->iommu = iommu;
- window->pte_offset = pte_offset;
window->table.it_blocksize = 16;
window->table.it_base = (unsigned long)iommu->ptab;
window->table.it_index = iommu->nid;
- window->table.it_offset = (offset >> IOMMU_PAGE_SHIFT) +
- window->pte_offset;
+ window->table.it_offset = (offset >> IOMMU_PAGE_SHIFT) + pte_offset;
window->table.it_size = size >> IOMMU_PAGE_SHIFT;
iommu_init_table(&window->table, iommu->nid);
--
1.5.2.rc1.1884.g59b20
^ permalink raw reply related
* [PATCH 2/8] Use it_offset not pte_offset in cell IOMMU code
From: Michael Ellerman @ 2008-02-29 7:33 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <fdd3edc0f2f3d2d6cade5cd695b8080d0da95a7f.1204270367.git.michael@ellerman.id.au>
The cell IOMMU tce build and free routines use pte_offset to convert
the index passed from the generic IOMMU code into a page table offset.
This takes into account the SPIDER_DMA_OFFSET which sets the top bit
of every DMA address.
However it doesn't cater for the IOMMU window starting at a non-zero
address, as the base of the window is not incorporated into pte_offset
at all.
As it turns out tbl->it_offset already contains the value we need, it
takes into account the base of the window and also pte_offset. So use
it instead!
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
---
arch/powerpc/platforms/cell/iommu.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/platforms/cell/iommu.c b/arch/powerpc/platforms/cell/iommu.c
index bbe8389..4e75919 100644
--- a/arch/powerpc/platforms/cell/iommu.c
+++ b/arch/powerpc/platforms/cell/iommu.c
@@ -200,7 +200,7 @@ static void tce_build_cell(struct iommu_table *tbl, long index, long npages,
(window->ioid & IOPTE_IOID_Mask);
#endif
- io_pte = (unsigned long *)tbl->it_base + (index - window->pte_offset);
+ io_pte = (unsigned long *)tbl->it_base + (index - tbl->it_offset);
for (i = 0; i < npages; i++, uaddr += IOMMU_PAGE_SIZE)
io_pte[i] = base_pte | (__pa(uaddr) & IOPTE_RPN_Mask);
@@ -232,7 +232,7 @@ static void tce_free_cell(struct iommu_table *tbl, long index, long npages)
| (window->ioid & IOPTE_IOID_Mask);
#endif
- io_pte = (unsigned long *)tbl->it_base + (index - window->pte_offset);
+ io_pte = (unsigned long *)tbl->it_base + (index - tbl->it_offset);
for (i = 0; i < npages; i++)
io_pte[i] = pte;
--
1.5.2.rc1.1884.g59b20
^ permalink raw reply related
* [PATCH 1/8] Clearup cell IOMMU fixed mapping terminology
From: Michael Ellerman @ 2008-02-29 7:33 UTC (permalink / raw)
To: linuxppc-dev
It's called the fixed mapping, not the static mapping.
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
---
arch/powerpc/platforms/cell/iommu.c | 8 ++++----
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/platforms/cell/iommu.c b/arch/powerpc/platforms/cell/iommu.c
index edab631..bbe8389 100644
--- a/arch/powerpc/platforms/cell/iommu.c
+++ b/arch/powerpc/platforms/cell/iommu.c
@@ -549,7 +549,7 @@ static void cell_dma_dev_setup_iommu(struct device *dev)
archdata->dma_data = &window->table;
}
-static void cell_dma_dev_setup_static(struct device *dev);
+static void cell_dma_dev_setup_fixed(struct device *dev);
static void cell_dma_dev_setup(struct device *dev)
{
@@ -557,7 +557,7 @@ static void cell_dma_dev_setup(struct device *dev)
/* Order is important here, these are not mutually exclusive */
if (get_dma_ops(dev) == &dma_iommu_fixed_ops)
- cell_dma_dev_setup_static(dev);
+ cell_dma_dev_setup_fixed(dev);
else if (get_pci_dma_ops() == &dma_iommu_ops)
cell_dma_dev_setup_iommu(dev);
else if (get_pci_dma_ops() == &dma_direct_ops)
@@ -858,7 +858,7 @@ static int dma_set_mask_and_switch(struct device *dev, u64 dma_mask)
return 0;
}
-static void cell_dma_dev_setup_static(struct device *dev)
+static void cell_dma_dev_setup_fixed(struct device *dev)
{
struct dev_archdata *archdata = &dev->archdata;
u64 addr;
@@ -894,7 +894,7 @@ static void cell_iommu_setup_fixed_ptab(struct cbe_iommu *iommu,
for (i = fbase; i < fbase + fsize; i++, uaddr += IOMMU_PAGE_SIZE) {
/* Don't touch the dynamic region */
if (i >= dbase && i < (dbase + dsize)) {
- pr_debug("iommu: static/dynamic overlap, skipping\n");
+ pr_debug("iommu: fixed/dynamic overlap, skipping\n");
continue;
}
io_pte[i] = base_pte | (__pa(uaddr) & IOPTE_RPN_Mask);
--
1.5.2.rc1.1884.g59b20
^ permalink raw reply related
* Re: undefined references to __udivdi3 on powerpc
From: Adrian Bunk @ 2008-02-29 6:56 UTC (permalink / raw)
To: Olaf Hering; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <20080228133718.GA8383@aepfle.de>
On Thu, Feb 28, 2008 at 02:37:18PM +0100, Olaf Hering wrote:
>
> While debugging __divdi3 calls in drivers/crypto/hifn_795x.c (due to the
> ndelay() delay call with a s64), I found even more breakage of that
> sort. This is after a allnoconfig with ARCH=powerpc in 2.6.25-rc3,
> plus CONFIG_MODULES=y and CONFIG_CRYPTO_DEV_HIFN_795X=y:
>
> LD .tmp_vmlinux1
> kernel/built-in.o: In function `update_xtime_cache':
> (.text+0x221a0): undefined reference to `__umoddi3'
> kernel/built-in.o: In function `update_xtime_cache':
> (.text+0x221c0): undefined reference to `__udivdi3'
> kernel/built-in.o: In function `getnstimeofday':
> (.text+0x22330): undefined reference to `__umoddi3'
> kernel/built-in.o: In function `getnstimeofday':
> (.text+0x22350): undefined reference to `__udivdi3'
> kernel/built-in.o: In function `timekeeping_resume':
> timekeeping.c:(.text+0x226a0): undefined reference to `__udivdi3'
> timekeeping.c:(.text+0x22778): undefined reference to `__umoddi3'
> timekeeping.c:(.text+0x22798): undefined reference to `__udivdi3'
> kernel/built-in.o: In function `update_wall_time':
> (.text+0x22c7c): undefined reference to `__umoddi3'
> kernel/built-in.o: In function `update_wall_time':
> (.text+0x22c9c): undefined reference to `__udivdi3'
> kernel/built-in.o: In function `update_wall_time':
> (.text+0x230f8): undefined reference to `__umoddi3'
> kernel/built-in.o: In function `update_wall_time':
> (.text+0x23118): undefined reference to `__udivdi3'
> kernel/built-in.o: In function `do_settimeofday':
> (.text+0x23520): undefined reference to `__udivdi3'
> kernel/built-in.o: In function `timekeeping_init':
> (.init.text+0x1870): undefined reference to `__udivdi3'
> make[1]: *** [.tmp_vmlinux1] Error 1
>
> But its not a regression, 2.6.24 allnoconfig does not link either on
> powerpc32.
>...
You didn't mention your gcc version, but you should only get these
errors when using the not yet released gcc 4.3.
And this issue is known for at about half a year.
> Olaf
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
^ permalink raw reply
* Re: [Cbe-oss-dev] Please pull 'for-2.6.25' branch of cell tree
From: Michael Ellerman @ 2008-02-29 6:13 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linuxppc-dev, paulus, cbe-oss-dev
In-Reply-To: <200802290612.56728.arnd@arndb.de>
[-- Attachment #1: Type: text/plain, Size: 885 bytes --]
On Fri, 2008-02-29 at 06:12 +0100, Arnd Bergmann wrote:
> Hi Paul,
>
> Please pull from:
>
> master.kernel.org:/pub/scm/linux/kernel/git/arnd/cell-2.6.git for-2.6.25
>
> To pick up a few small fixes for the cell platform. Most of it is a follow-up
> to the IOMMU rework that got merged in 2.6.25-rc1 and caused problems on
> machines with large amounts of memory.
Sorry, I have updated versions of the IOMMU patches to send. Arnd is
away for the weekend, so Paul if you just want to cherry pick the other
fixes that might work. I'll send the updated IOMMU patches momentarily.
Apologies for the churn.
cheers
--
Michael Ellerman
OzLabs, IBM Australia Development Lab
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH 1/2] firewire: endianess fix
From: Benjamin Herrenschmidt @ 2008-02-29 6:00 UTC (permalink / raw)
To: Jarod Wilson
Cc: Kristian Hoegsberg, linux-kernel, linuxppc-dev, Stefan Richter,
sparclinux, linux1394-devel, Sam Ravnborg, Harvey Harrison
In-Reply-To: <47C79CB1.6050104@redhat.com>
> Still no luck finding one here. The person I was thinking of has a
> Lombard, which has no firewire. I did get ahold of a 667MHz Titanium,
> but its got an Agere FW323. Pretty sure my old man actually has a Pismo,
> but its about a 3000 mile drive over to my folks house. The search
> continues... I wonder how many people still actually 1) have a machine
> with this controller, 2) are running Linux on it and 3) use firewire
> devices with it. Both of you, please speak up, we're trying to help you!
> (if only out of morbid curiosity to see this mythical goofy controller).
First gen titanium (400/500 Mhz models) might... Paulus has one at home
I think, I'll chase that up here.
Cheers,
Ben.
^ permalink raw reply
* dtc: Make -I dtb mode use fill_fullpaths()
From: David Gibson @ 2008-02-29 5:51 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev
At present -I dts and -I fs modes both use the fill_fullpaths() helper
function to fill in the fullpath and basenamelen fields of struct
node, which are useful in later parts of the code. -I dtb mode,
however, fills these in itself.
This patch simplifies flattree.c by making -I dtb mode use
fill_fullpaths() like the others.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Index: dtc/flattree.c
===================================================================
--- dtc.orig/flattree.c 2008-02-29 13:38:15.000000000 +1100
+++ dtc/flattree.c 2008-02-29 16:46:02.000000000 +1100
@@ -704,59 +704,37 @@ static struct reserve_info *flat_read_me
static char *nodename_from_path(const char *ppath, const char *cpath)
{
- const char *lslash;
int plen;
- lslash = strrchr(cpath, '/');
- if (! lslash)
- return NULL;
+ plen = strlen(ppath);
- plen = lslash - cpath;
+ if (!strneq(ppath, cpath, plen))
+ die("Path \"%s\" is not valid as a child of \"%s\"\n",
+ cpath, ppath);
- if (streq(cpath, "/") && streq(ppath, ""))
- return "";
+ /* root node is a special case */
+ if (!streq(ppath, "/"))
+ plen++;
- if ((plen == 0) && streq(ppath, "/"))
- return strdup(lslash+1);
-
- if (! strneq(ppath, cpath, plen))
- return NULL;
-
- return strdup(lslash+1);
-}
-
-static int find_basenamelen(const char *name)
-{
- const char *atpos = strchr(name, '@');
-
- if (atpos)
- return atpos - name;
- else
- return strlen(name);
+ return strdup(cpath + plen);
}
static struct node *unflatten_tree(struct inbuf *dtbuf,
struct inbuf *strbuf,
- const char *parent_path, int flags)
+ const char *parent_flatname, int flags)
{
struct node *node;
+ char *flatname;
u32 val;
node = build_node(NULL, NULL);
- if (flags & FTF_FULLPATH) {
- node->fullpath = flat_read_string(dtbuf);
- node->name = nodename_from_path(parent_path, node->fullpath);
-
- if (! node->name)
- die("Path \"%s\" is not valid as a child of \"%s\"\n",
- node->fullpath, parent_path);
- } else {
- node->name = flat_read_string(dtbuf);
- node->fullpath = join_path(parent_path, node->name);
- }
+ flatname = flat_read_string(dtbuf);
- node->basenamelen = find_basenamelen(node->name);
+ if (flags & FTF_FULLPATH)
+ node->name = nodename_from_path(parent_flatname, flatname);
+ else
+ node->name = flatname;
do {
struct property *prop;
@@ -773,8 +751,7 @@ static struct node *unflatten_tree(struc
break;
case FDT_BEGIN_NODE:
- child = unflatten_tree(dtbuf,strbuf, node->fullpath,
- flags);
+ child = unflatten_tree(dtbuf,strbuf, flatname, flags);
add_child(node, child);
break;
Index: dtc/dtc.c
===================================================================
--- dtc.orig/dtc.c 2008-02-28 12:55:04.000000000 +1100
+++ dtc/dtc.c 2008-02-29 16:16:07.000000000 +1100
@@ -55,7 +55,7 @@ char *join_path(const char *path, const
return str;
}
-void fill_fullpaths(struct node *tree, const char *prefix)
+static void fill_fullpaths(struct node *tree, const char *prefix)
{
struct node *child;
const char *unit;
@@ -208,6 +208,7 @@ int main(int argc, char *argv[])
if (! bi || ! bi->dt || bi->error)
die("Couldn't read input tree\n");
+ fill_fullpaths(bi->dt, "");
process_checks(force, bi);
if (streq(outname, "-")) {
Index: dtc/dtc.h
===================================================================
--- dtc.orig/dtc.h 2008-02-28 17:02:38.000000000 +1100
+++ dtc/dtc.h 2008-02-29 16:16:07.000000000 +1100
@@ -264,6 +264,5 @@ struct boot_info *dt_from_fs(const char
/* misc */
char *join_path(const char *path, const char *name);
-void fill_fullpaths(struct node *tree, const char *prefix);
#endif /* _DTC_H */
Index: dtc/fstree.c
===================================================================
--- dtc.orig/fstree.c 2008-02-28 12:55:04.000000000 +1100
+++ dtc/fstree.c 2008-02-29 16:16:07.000000000 +1100
@@ -87,8 +87,6 @@ struct boot_info *dt_from_fs(const char
tree = read_fstree(dirname);
tree = name_node(tree, "", NULL);
- fill_fullpaths(tree, "");
-
return build_boot_info(NULL, tree);
}
Index: dtc/treesource.c
===================================================================
--- dtc.orig/treesource.c 2008-02-28 17:02:36.000000000 +1100
+++ dtc/treesource.c 2008-02-29 16:16:07.000000000 +1100
@@ -37,8 +37,6 @@ struct boot_info *dt_from_source(const c
if (yyparse() != 0)
return NULL;
- fill_fullpaths(the_boot_info->dt, "");
-
the_boot_info->error = treesource_error;
return the_boot_info;
}
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: [PATCH 1/2] firewire: endianess fix
From: Jarod Wilson @ 2008-02-29 5:48 UTC (permalink / raw)
To: benh
Cc: Kristian Hoegsberg, linux-kernel, linuxppc-dev, Stefan Richter,
sparclinux, linux1394-devel, Sam Ravnborg, Harvey Harrison
In-Reply-To: <1204241162.15052.393.camel@pasglop>
Benjamin Herrenschmidt wrote:
> On Thu, 2008-02-28 at 13:42 -0500, Jarod Wilson wrote:
>> On Thursday 28 February 2008 01:25:59 am Benjamin Herrenschmidt wrote:
>>>> Under Mac OS X, system.log says "FireWire (OHCI) Apple ID 31 built-in now
>>>> active". Could still be lucent though, judging by the subsys device ID of
>>>> 5811, which matches up w/the Lucent/Agere FW323. But no, apparently I
>>>> don't have the interesting one.
>>> Well, it's interesting in the sense that it's a "normal" OHCI then on a
>>> BE machine :-) My Pismo, which had the weirdo one, unfortunately died a
>>> while ago. I'll see if I can find another machine with that one in.
>> Ah, the pismo has it, eh? I think I may actually know of someone in the office
>> that still has one of those that I might be able to borrow and poke at...
>
> I -think- it has it... Pismo definitely has one of the first variant of
> UniNorth with "working" FW afaik.
>
> The first UniNorth was used in the first "toilet-seat" ibook, but I
> think this one didn't have firewire, or a non-working one... and in the
> first Sawtooth G4 for which FW and Ethernet even were separate PCI chips
> because the ones in UniNorth were too broken.
>
> It's possible that early G4 titanium powerbooks or other model of FW
> iBooks have that UniNorth FW variant too.
Still no luck finding one here. The person I was thinking of has a
Lombard, which has no firewire. I did get ahold of a 667MHz Titanium,
but its got an Agere FW323. Pretty sure my old man actually has a Pismo,
but its about a 3000 mile drive over to my folks house. The search
continues... I wonder how many people still actually 1) have a machine
with this controller, 2) are running Linux on it and 3) use firewire
devices with it. Both of you, please speak up, we're trying to help you!
(if only out of morbid curiosity to see this mythical goofy controller).
--
Jarod Wilson
jwilson@redhat.com
^ permalink raw reply
* Please pull 'for-2.6.25' branch of cell tree
From: Arnd Bergmann @ 2008-02-29 5:12 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev, cbe-oss-dev
Hi Paul,
Please pull from:
master.kernel.org:/pub/scm/linux/kernel/git/arnd/cell-2.6.git for-2.6.25
To pick up a few small fixes for the cell platform. Most of it is a follow-up
to the IOMMU rework that got merged in 2.6.25-rc1 and caused problems on
machines with large amounts of memory.
The fixes for oprofile and ptrace are not regressions, but are fixing
functionality that was broken on cell but has always worked on the
other platforms.
Thanks,
Arnd <><
Author: Michael Ellerman <michael@ellerman.id.au>
[POWERPC] Convert the cell IOMMU fixed mapping to 16M IOMMU pages
[POWERPC] Allow for different IOMMU page sizes in cell IOMMU code
[POWERPC] Cell IOMMU: n_pte_pages is in 4K page units, not IOMMU_PAGE_SIZE
[POWERPC] Split setup of IOMMU stab and ptab, allocate dynamic/fixed ptabs separately
[POWERPC] Move allocation of cell IOMMU pad page
[POWERPC] Remove unused pte_offset variable
[POWERPC] Use it_offset not pte_offset in cell IOMMU code
[POWERPC] Clearup cell IOMMU fixed mapping terminology
Author: Jens Osterkamp <jens@de.ibm.com>
[POWERPC] enable hardware watchpoints on cell blades
[POWERPC] move celleb DABRX definitions
Author: Bob Nelson <rrnelson@us.ibm.com>
[POWERPC] OProfile: enable callgraph support for Cell
arch/powerpc/oprofile/op_model_cell.c | 2
arch/powerpc/platforms/cell/iommu.c | 144 +++++++++++++++++++---------------
arch/powerpc/platforms/cell/setup.c | 7 +
arch/powerpc/platforms/celleb/beat.h | 3
include/asm-powerpc/reg.h | 3
5 files changed, 92 insertions(+), 67 deletions(-)
^ permalink raw reply
* Re: [PATCH 0/3] hotplug memory remove updates
From: Badari Pulavarty @ 2008-02-29 4:51 UTC (permalink / raw)
To: Nathan Lynch; +Cc: linuxppc-dev
In-Reply-To: <20080229013957.GQ16241@localdomain>
Nathan Lynch wrote:
> Badari Pulavarty wrote:
>
>> Hi Paul,
>>
>> Here are the hotplug memory remove updates for 2.6.25-rc2-mm1.
>>
>
> How have these been tested? Have you initiated a memory remove
> operation from the HMC? That's the only way to catch some bugs...
>
Yes, They are testing from HMC + running "drmgr" command manually to
hash out
all the issues.
Thanks,
Badari
^ permalink raw reply
* [PATCH] [POWERPC] pci: fix bogus test for unassigned resources
From: Benjamin Herrenschmidt @ 2008-02-29 3:58 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
A bogus test for unassigned resources that came from our 32 bits
PCI code ended up being "merged" by my previous patch series,
breaking some 64 bits setups where devices have legal resources
ending at 0xffffffff.
This fixes it by completely changing the test. We now test for
res->start == 0, as the generic code expects, and we also only
do so on platforms that don't have the PPC_PCI_PROBE_ONLY flag
set, as there are cases of pSeries and iSeries where it could
be a valid value and those can't reassign devices.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
arch/powerpc/kernel/pci-common.c | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
--- linux-work.orig/arch/powerpc/kernel/pci-common.c 2008-02-29 13:37:51.000000000 +1100
+++ linux-work/arch/powerpc/kernel/pci-common.c 2008-02-29 14:39:28.000000000 +1100
@@ -748,7 +748,13 @@ static void __devinit pcibios_fixup_reso
struct resource *res = dev->resource + i;
if (!res->flags)
continue;
- if (res->end == 0xffffffff) {
+ /* On platforms that have PPC_PCI_PROBE_ONLY set, we don't
+ * consider 0 as an unassigned BAR value. It's technically
+ * a valid value, but linux doesn't like it... so when we can
+ * re-assign things, we do so, but if we can't, we keep it
+ * around and hope for the best...
+ */
+ if (res->start == 0 && !(ppc_pci_flags & PPC_PCI_PROBE_ONLY)) {
pr_debug("PCI:%s Resource %d %016llx-%016llx [%x] is unassigned\n",
pci_name(dev), i,
(unsigned long long)res->start,
^ permalink raw reply
* Re: [dtc] breaking out libfdt from dtc so other progs can use it
From: Jerry Van Baren @ 2008-02-29 2:53 UTC (permalink / raw)
To: jyoung5; +Cc: linuxppc-dev, David Gibson
In-Reply-To: <1204228953.12181.15.camel@thinkpad.austin.ibm.com>
Jerone Young wrote:
> On Thu, 2008-02-28 at 12:59 -0600, Josh Boyer wrote:
>> On Thu, 28 Feb 2008 10:30:44 -0600
>> Jerone Young <jyoung5@us.ibm.com> wrote:
[big snip]
>> You still haven't explained why maintenance is harder or somehow less
>> doable by having it in the dtc repo. Maintenance is very much the
>> concern of the upstream developers, which seem to be saying it's not a
>> problem for them...
>
> I guess what I see libfdt as something like shared userspace library. At
> the moment dtc is the only userspace project to use it. So it make
> perfect since to keep it with the source and not separated.
>
> Though when other projects need it .. the option of having to try to
> figure out what version of dtc to grab so understand what libfdt is
> usable, can be a bit of a pain.
>
> Though I can't really argue that you can't get around this by just
> downloading dtc and grabbing out the libfdt package..though it does
> cause some indirection.
FWIIW, that is what the u-boot project is doing. The last pass, I
actually extracted the libfdt git patch(es) and then applied them to the
u-boot tree so that the history would be carried over. The libfdt
portion is now quite stable and I don't see major changes coming that
would cause this methodology to be a problem.
Best regards,
gvb
^ permalink raw reply
* Re: [PATCH 4/4] Emerson KSI8560 base support
From: Stephen Rothwell @ 2008-02-29 2:34 UTC (permalink / raw)
To: Alexandr Smirnov; +Cc: linuxppc-dev
In-Reply-To: <20080228185202.GE26971@ru.mvista.com>
[-- Attachment #1: Type: text/plain, Size: 1692 bytes --]
Hi Alexandr,
On Thu, 28 Feb 2008 21:52:02 +0300 Alexandr Smirnov <asmirnov@ru.mvista.com> wrote:
>
> +void __iomem *cpld_base = NULL;
Should this be static?
> +static void cpm2_cascade(unsigned int irq, struct irq_desc *desc)
> +{
> + int cascade_irq;
> +
> + while ((cascade_irq = cpm2_get_irq()) >= 0) {
> + generic_handle_irq(cascade_irq);
> + }
We normally don't bracket single line blocks.
> +static void __init ksi8560_pic_init(void)
> +{
> + struct mpic *mpic;
> + struct resource r;
> + struct device_node *np = NULL;
> +#ifdef CONFIG_CPM2
> + int irq;
> +#endif
> +
> + np = of_find_node_by_type(np, "open-pic");
You can pass NULL as the first argument here, so you don't need the
initialisation of "np" above.
> +static struct cpm_pin ksi8560_pins[] = {
This should be marked __init.
> +static void ksi8560_show_cpuinfo(struct seq_file *m)
> +{
> + seq_printf(m, "Hardware rev\t: %d\n",
> + in_8(cpld_base + KSI8560_CPLD_HVR));
What if cpld_base is NULL?
> +static struct of_device_id __initdata of_bus_ids[] = {
> + { .type = "soc", },
> + { .name = "cpm", },
> + { .name = "localbus", },
> + {},
> +};
> +
> +static int __init declare_of_platform_devices(void)
> +{
> + if (!machine_is(ksi8560))
> + return 0;
You don't need this test because this is a machine_init_call.
> +static int __init ksi8560_probe(void)
> +{
> + unsigned long root = of_get_flat_dt_root();
> +
> + return of_flat_dt_is_compatible(root, "emerson,KSI8560");
You need to include asm/prom.h to use these routines.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH 0/8] pseries: phyp dump: hypervisor-assisted dump
From: Michael Ellerman @ 2008-02-29 2:20 UTC (permalink / raw)
To: Manish Ahuja; +Cc: ppc-dev, Linas Vepstas, paulus
In-Reply-To: <47C74A66.1060105@austin.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 589 bytes --]
On Thu, 2008-02-28 at 17:57 -0600, Manish Ahuja wrote:
> Changes from previous version:
>
> The only changes are in patch 2.
> moved early_init_dt_scan_phyp_dump from rtas.c to phyp_dump.c
> Added dummy function in phyp_dump.h
This fixes the build failures I was seeing!
http://kisskb.ellerman.id.au/kisskb/head/664/
cheers
--
Michael Ellerman
OzLabs, IBM Australia Development Lab
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH 0/3] hotplug memory remove updates
From: Geoff Levand @ 2008-02-29 2:19 UTC (permalink / raw)
To: Nathan Lynch; +Cc: linuxppc-dev, Badari Pulavarty
In-Reply-To: <20080229013957.GQ16241@localdomain>
Hi.
Nathan Lynch wrote:
> Badari Pulavarty wrote:
>> Hi Paul,
>>
>> Here are the hotplug memory remove updates for 2.6.25-rc2-mm1.
>
> How have these been tested? Have you initiated a memory remove
> operation from the HMC? That's the only way to catch some bugs...
I'm wondering how the memory hot un-plug is initiated on the pseries.
Could you tell me about this HMC? Is it an application running in
the lpar, or is it an external entity?
Is there a 'standard' interface from userspace that can be used to
trigger the hot-unplug sequence? I'm asking because PS3's lv1
hypervisor supports hot un-plug of memory, but it would need to be
triggered from some kind of management application running in in
userspace.
-Geoff
^ permalink raw reply
* Re: [PATCH 2/4] Emerson KSI8560 device tree
From: David Gibson @ 2008-02-29 2:17 UTC (permalink / raw)
To: Alexandr Smirnov; +Cc: linuxppc-dev
In-Reply-To: <20080228184727.GC26971@ru.mvista.com>
On Thu, Feb 28, 2008 at 09:47:27PM +0300, Alexandr Smirnov wrote:
>
> diff --git a/arch/powerpc/boot/dts/ksi8560.dts
> b/arch/powerpc/boot/dts/ksi8560.dts
What Scott said, plus:
[snip]
> + i2c@3000 {
> + device_type = "i2c";
No device_type here either.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: [PATCH 1/4] Emerson KSI8560 bootwrapper
From: Stephen Rothwell @ 2008-02-29 2:11 UTC (permalink / raw)
To: Alexandr Smirnov; +Cc: linuxppc-dev
In-Reply-To: <20080228184438.GB26971@ru.mvista.com>
[-- Attachment #1: Type: text/plain, Size: 308 bytes --]
On Thu, 28 Feb 2008 21:44:38 +0300 Alexandr Smirnov <asmirnov@ru.mvista.com> wrote:
>
>
> diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile
These patches all need Signed-off-by lines and diffstat is useful.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH 0/3] hotplug memory remove updates
From: Nathan Lynch @ 2008-02-29 1:39 UTC (permalink / raw)
To: Badari Pulavarty; +Cc: linuxppc-dev
In-Reply-To: <1204217028.28696.10.camel@dyn9047017100.beaverton.ibm.com>
Badari Pulavarty wrote:
> Hi Paul,
>
> Here are the hotplug memory remove updates for 2.6.25-rc2-mm1.
How have these been tested? Have you initiated a memory remove
operation from the HMC? That's the only way to catch some bugs...
^ permalink raw reply
* Re: [PATCH 3/3] ppc64-specific memory notifier support
From: Michael Ellerman @ 2008-02-29 1:03 UTC (permalink / raw)
To: Nathan Lynch; +Cc: linuxppc-dev, Badari Pulavarty
In-Reply-To: <20080229003906.GP16241@localdomain>
[-- Attachment #1: Type: text/plain, Size: 2439 bytes --]
On Thu, 2008-02-28 at 18:39 -0600, Nathan Lynch wrote:
> Michael Ellerman wrote:
> > On Thu, 2008-02-28 at 08:46 -0800, Badari Pulavarty wrote:
> > > Hotplug memory notifier for ppc64. This gets invoked by writing
> > > the device-node that needs to be removed to /proc/ppc64/ofdt.
> > > We need to adjust the sections and remove sysfs entries by
> > > calling __remove_pages(). Then call arch specific code to
> > > get rid of htab mappings for the section of memory.
> > >
> > > Signed-off-by: Badari Pulavarty <pbadari@us.ibm.com>
> > > ---
> > > arch/powerpc/platforms/pseries/Makefile | 1
> > > arch/powerpc/platforms/pseries/hotplug-memory.c | 98 ++++++++++++++++++++++++
> > > 2 files changed, 99 insertions(+)
> > >
> > > Index: linux-2.6.25-rc2/arch/powerpc/platforms/pseries/hotplug-memory.c
> > > ===================================================================
> > > --- /dev/null 1970-01-01 00:00:00.000000000 +0000
> > > +++ linux-2.6.25-rc2/arch/powerpc/platforms/pseries/hotplug-memory.c 2008-02-28 08:20:14.000000000 -0800
> >
> > > +
> > > +static struct notifier_block pseries_smp_nb = {
> > > + .notifier_call = pseries_memory_notifier,
> > > +};
> > > +
> > > +static int __init pseries_memory_hotplug_init(void)
> > > +{
> > > + if (firmware_has_feature(FW_FEATURE_LPAR))
> > > + pSeries_reconfig_notifier_register(&pseries_smp_nb);
> > > +
> > > + return 0;
> > > +}
> > > +arch_initcall(pseries_memory_hotplug_init);
> >
> > This is going to fire on non-pseries LPAR platforms, like iSeries and
> > PS3. Which is not what you want I think.
>
> Well, the notifier will be registered, yes, but it will never be
> called because that path is reachable only from a write to
> /proc/ppc64/ofdt, which is not created on non-pseries.
Sure. Still seems better not to register it in the first place.
> Maybe it should be
>
> machine_device_initcall(pseries, pseries_memory_hotplug_init);
I think so.
> (and pseries_cpu_hotplug_init in hotplug-cpu.c should be changed to
> machine_arch_initcall)
Yeah I noticed that was not guarded as well, and I think I'm culpable
for that :)
cheers
--
Michael Ellerman
OzLabs, IBM Australia Development Lab
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* [PATCH 8/8] pseries: phyp dump: config file
From: Manish Ahuja @ 2008-02-29 0:35 UTC (permalink / raw)
To: linuxppc-dev, paulus, michael; +Cc: mahuja, linasvepstas
In-Reply-To: <47C74A66.1060105@austin.ibm.com>
Add hypervisor-assisted dump to kernel config
Signed-off-by: Linas Vepstas <linasvepstas@gmail.com>
-----
arch/powerpc/Kconfig | 11 +++++++++++
1 file changed, 11 insertions(+)
Index: 2.6.25-rc1/arch/powerpc/Kconfig
===================================================================
--- 2.6.25-rc1.orig/arch/powerpc/Kconfig 2008-02-18 03:22:06.000000000 -0600
+++ 2.6.25-rc1/arch/powerpc/Kconfig 2008-02-18 03:22:45.000000000 -0600
@@ -306,6 +306,17 @@ config CRASH_DUMP
Don't change this unless you know what you are doing.
+config PHYP_DUMP
+ bool "Hypervisor-assisted dump (EXPERIMENTAL)"
+ depends on PPC_PSERIES && EXPERIMENTAL
+ default y
+ help
+ Hypervisor-assisted dump is meant to be a kdump replacement
+ offering robustness and speed not possible without system
+ hypervisor assistence.
+
+ If unsure, say "Y"
+
config PPCBUG_NVRAM
bool "Enable reading PPCBUG NVRAM during boot" if PPLUS || LOPEC
default y if PPC_PREP
^ permalink raw reply
* [PATCH 7/8] pseries: phyp dump: Tracking memory range freed.
From: Manish Ahuja @ 2008-02-29 0:33 UTC (permalink / raw)
To: linuxppc-dev, paulus, michael; +Cc: mahuja, linasvepstas
In-Reply-To: <47C74A66.1060105@austin.ibm.com>
This patch tracks the size freed. For now it does a simple
rudimentary calculation of the ranges freed. The idea is
to keep it simple at the external shell script level and
send in large chunks for now.
Signed-off-by: Manish Ahuja <mahuja@us.ibm.com>
-----
---
arch/powerpc/platforms/pseries/phyp_dump.c | 35 +++++++++++++++++++++++++++++
1 file changed, 35 insertions(+)
Index: 2.6.25-rc1/arch/powerpc/platforms/pseries/phyp_dump.c
===================================================================
--- 2.6.25-rc1.orig/arch/powerpc/platforms/pseries/phyp_dump.c 2008-02-28 23:36:47.000000000 -0600
+++ 2.6.25-rc1/arch/powerpc/platforms/pseries/phyp_dump.c 2008-02-28 23:36:49.000000000 -0600
@@ -262,6 +262,39 @@ void release_memory_range(unsigned long
}
}
+/**
+ * track_freed_range -- Counts the range being freed.
+ * Once the counter goes to zero, it re-registers dump for
+ * future use.
+ */
+static void
+track_freed_range(unsigned long addr, unsigned long length)
+{
+ static unsigned long scratch_area_size, reserved_area_size;
+
+ if (addr < phyp_dump_info->init_reserve_start)
+ return;
+
+ if ((addr >= phyp_dump_info->init_reserve_start) &&
+ (addr <= phyp_dump_info->init_reserve_start +
+ phyp_dump_info->init_reserve_size))
+ reserved_area_size += length;
+
+ if ((addr >= phyp_dump_info->reserved_scratch_addr) &&
+ (addr <= phyp_dump_info->reserved_scratch_addr +
+ phyp_dump_info->reserved_scratch_size))
+ scratch_area_size += length;
+
+ if ((reserved_area_size == phyp_dump_info->init_reserve_size) &&
+ (scratch_area_size == phyp_dump_info->reserved_scratch_size)) {
+
+ invalidate_last_dump(&phdr,
+ phyp_dump_info->reserved_scratch_addr);
+ register_dump_area(&phdr,
+ phyp_dump_info->reserved_scratch_addr);
+ }
+}
+
/* ------------------------------------------------- */
/**
* sysfs_release_region -- sysfs interface to release memory range.
@@ -286,6 +319,8 @@ static ssize_t store_release_region(stru
if (ret != 2)
return -EINVAL;
+ track_freed_range(start_addr, length);
+
/* Range-check - don't free any reserved memory that
* wasn't reserved for phyp-dump */
if (start_addr < phyp_dump_info->init_reserve_start)
^ permalink raw reply
* [PATCH 6/8] pseries: phyp dump: Invalidate and print dump areas.
From: Manish Ahuja @ 2008-02-29 0:32 UTC (permalink / raw)
To: linuxppc-dev, paulus, michael; +Cc: mahuja, linasvepstas
In-Reply-To: <47C74A66.1060105@austin.ibm.com>
Routines to
a. invalidate dump
b. Calculate region that is reserved and needs to be freed. This is
exported through sysfs interface.
Unregister has been removed for now as it wasn't being used.
Signed-off-by: Manish Ahuja <mahuja@us.ibm.com>
-----
---
arch/powerpc/platforms/pseries/phyp_dump.c | 83 ++++++++++++++++++++++++++---
include/asm-powerpc/phyp_dump.h | 3 +
2 files changed, 80 insertions(+), 6 deletions(-)
Index: 2.6.25-rc1/arch/powerpc/platforms/pseries/phyp_dump.c
===================================================================
--- 2.6.25-rc1.orig/arch/powerpc/platforms/pseries/phyp_dump.c 2008-02-28 23:36:45.000000000 -0600
+++ 2.6.25-rc1/arch/powerpc/platforms/pseries/phyp_dump.c 2008-02-28 23:36:47.000000000 -0600
@@ -71,6 +71,10 @@ static struct phyp_dump_header phdr;
#define DUMP_SOURCE_CPU 0x0001
#define DUMP_SOURCE_HPTE 0x0002
#define DUMP_SOURCE_RMO 0x0011
+#define DUMP_ERROR_FLAG 0x2000
+#define DUMP_TRIGGERED 0x4000
+#define DUMP_PERFORMED 0x8000
+
/**
* init_dump_header() - initialize the header declaring a dump
@@ -182,9 +186,15 @@ static void print_dump_header(const stru
static void register_dump_area(struct phyp_dump_header *ph, unsigned long addr)
{
int rc;
- ph->cpu_data.destination_address += addr;
- ph->hpte_data.destination_address += addr;
- ph->kernel_data.destination_address += addr;
+
+ /* Add addr value if not initialized before */
+ if (ph->cpu_data.destination_address == 0) {
+ ph->cpu_data.destination_address += addr;
+ ph->hpte_data.destination_address += addr;
+ ph->kernel_data.destination_address += addr;
+ }
+
+ /* ToDo Invalidate kdump and free memory range. */
do {
rc = rtas_call(ibm_configure_kernel_dump, 3, 1, NULL,
@@ -198,6 +208,30 @@ static void register_dump_area(struct ph
}
}
+static
+void invalidate_last_dump(struct phyp_dump_header *ph, unsigned long addr)
+{
+ int rc;
+
+ /* Add addr value if not initialized before */
+ if (ph->cpu_data.destination_address == 0) {
+ ph->cpu_data.destination_address += addr;
+ ph->hpte_data.destination_address += addr;
+ ph->kernel_data.destination_address += addr;
+ }
+
+ do {
+ rc = rtas_call(ibm_configure_kernel_dump, 3, 1, NULL,
+ 2, ph, sizeof(struct phyp_dump_header));
+ } while (rtas_busy_delay(rc));
+
+ if (rc) {
+ printk(KERN_ERR "phyp-dump: unexpected error (%d) "
+ "on invalidate\n", rc);
+ print_dump_header(ph);
+ }
+}
+
/* ------------------------------------------------- */
/**
* release_memory_range -- release memory previously lmb_reserved
@@ -208,8 +242,8 @@ static void register_dump_area(struct ph
* lmb_reserved in early boot. The released memory becomes
* available for genreal use.
*/
-static void
-release_memory_range(unsigned long start_pfn, unsigned long nr_pages)
+static
+void release_memory_range(unsigned long start_pfn, unsigned long nr_pages)
{
struct page *rpage;
unsigned long end_pfn;
@@ -270,8 +304,29 @@ static ssize_t store_release_region(stru
return count;
}
+static ssize_t show_release_region(struct kobject *kobj,
+ struct kobj_attribute *attr, char *buf)
+{
+ u64 second_addr_range;
+
+ /* total reserved size - start of scratch area */
+ second_addr_range = phyp_dump_info->init_reserve_size -
+ phyp_dump_info->reserved_scratch_size;
+ return sprintf(buf, "CPU:0x%lx-0x%lx: HPTE:0x%lx-0x%lx:"
+ " DUMP:0x%lx-0x%lx, 0x%lx-0x%lx:\n",
+ phdr.cpu_data.destination_address,
+ phdr.cpu_data.length_copied,
+ phdr.hpte_data.destination_address,
+ phdr.hpte_data.length_copied,
+ phdr.kernel_data.destination_address,
+ phdr.kernel_data.length_copied,
+ phyp_dump_info->init_reserve_start,
+ second_addr_range);
+}
+
static struct kobj_attribute rr = __ATTR(release_region, 0600,
- NULL, store_release_region);
+ show_release_region,
+ store_release_region);
static int __init phyp_dump_setup(void)
{
@@ -314,6 +369,22 @@ static int __init phyp_dump_setup(void)
return 0;
}
+ /* re-register the dump area, if old dump was invalid */
+ if ((dump_header) && (dump_header->status & DUMP_ERROR_FLAG)) {
+ invalidate_last_dump(&phdr, dump_area_start);
+ register_dump_area(&phdr, dump_area_start);
+ return 0;
+ }
+
+ if (dump_header) {
+ phyp_dump_info->reserved_scratch_addr =
+ dump_header->cpu_data.destination_address;
+ phyp_dump_info->reserved_scratch_size =
+ dump_header->cpu_data.source_length +
+ dump_header->hpte_data.source_length +
+ dump_header->kernel_data.source_length;
+ }
+
/* Should we create a dump_subsys, analogous to s390/ipl.c ? */
rc = sysfs_create_file(kernel_kobj, &rr.attr);
if (rc)
Index: 2.6.25-rc1/include/asm-powerpc/phyp_dump.h
===================================================================
--- 2.6.25-rc1.orig/include/asm-powerpc/phyp_dump.h 2008-02-28 22:05:25.000000000 -0600
+++ 2.6.25-rc1/include/asm-powerpc/phyp_dump.h 2008-02-28 23:36:47.000000000 -0600
@@ -30,6 +30,9 @@ struct phyp_dump {
/* store cpu & hpte size */
unsigned long cpu_state_size;
unsigned long hpte_region_size;
+ /* previous scratch area values */
+ unsigned long reserved_scratch_addr;
+ unsigned long reserved_scratch_size;
};
extern struct phyp_dump *phyp_dump_info;
^ permalink raw reply
* [PATCH 5/8] pseries: phyp dump: debugging print routines.
From: Manish Ahuja @ 2008-02-29 0:31 UTC (permalink / raw)
To: linuxppc-dev, paulus, michael; +Cc: mahuja, linasvepstas
In-Reply-To: <47C74A66.1060105@austin.ibm.com>
Provide some basic debugging support.
Signed-off-by: Manish Ahuja <mahuja@us.ibm.com>
Signed-off-by: Linas Vepstas <linasvepstas@gmail.com>
-----
arch/powerpc/platforms/pseries/phyp_dump.c | 61 ++++++++++++++++++++++++++++-
1 file changed, 59 insertions(+), 2 deletions(-)
Index: 2.6.25-rc1/arch/powerpc/platforms/pseries/phyp_dump.c
===================================================================
--- 2.6.25-rc1.orig/arch/powerpc/platforms/pseries/phyp_dump.c 2008-02-28 23:36:42.000000000 -0600
+++ 2.6.25-rc1/arch/powerpc/platforms/pseries/phyp_dump.c 2008-02-28 23:36:45.000000000 -0600
@@ -124,6 +124,61 @@ static unsigned long init_dump_header(st
return addr_offset;
}
+static void print_dump_header(const struct phyp_dump_header *ph)
+{
+#ifdef DEBUG
+ printk(KERN_INFO "dump header:\n");
+ /* setup some ph->sections required */
+ printk(KERN_INFO "version = %d\n", ph->version);
+ printk(KERN_INFO "Sections = %d\n", ph->num_of_sections);
+ printk(KERN_INFO "Status = 0x%x\n", ph->status);
+
+ /* No ph->disk, so all should be set to 0 */
+ printk(KERN_INFO "Offset to first section 0x%x\n",
+ ph->first_offset_section);
+ printk(KERN_INFO "dump disk sections should be zero\n");
+ printk(KERN_INFO "dump disk section = %d\n", ph->dump_disk_section);
+ printk(KERN_INFO "block num = %ld\n", ph->block_num_dd);
+ printk(KERN_INFO "number of blocks = %ld\n", ph->num_of_blocks_dd);
+ printk(KERN_INFO "dump disk offset = %d\n", ph->offset_dd);
+ printk(KERN_INFO "Max auto time= %d\n", ph->maxtime_to_auto);
+
+ /*set cpu state and hpte states as well scratch pad area */
+ printk(KERN_INFO " CPU AREA \n");
+ printk(KERN_INFO "cpu dump_flags =%d\n", ph->cpu_data.dump_flags);
+ printk(KERN_INFO "cpu source_type =%d\n", ph->cpu_data.source_type);
+ printk(KERN_INFO "cpu error_flags =%d\n", ph->cpu_data.error_flags);
+ printk(KERN_INFO "cpu source_address =%lx\n",
+ ph->cpu_data.source_address);
+ printk(KERN_INFO "cpu source_length =%lx\n",
+ ph->cpu_data.source_length);
+ printk(KERN_INFO "cpu length_copied =%lx\n",
+ ph->cpu_data.length_copied);
+
+ printk(KERN_INFO " HPTE AREA \n");
+ printk(KERN_INFO "HPTE dump_flags =%d\n", ph->hpte_data.dump_flags);
+ printk(KERN_INFO "HPTE source_type =%d\n", ph->hpte_data.source_type);
+ printk(KERN_INFO "HPTE error_flags =%d\n", ph->hpte_data.error_flags);
+ printk(KERN_INFO "HPTE source_address =%lx\n",
+ ph->hpte_data.source_address);
+ printk(KERN_INFO "HPTE source_length =%lx\n",
+ ph->hpte_data.source_length);
+ printk(KERN_INFO "HPTE length_copied =%lx\n",
+ ph->hpte_data.length_copied);
+
+ printk(KERN_INFO " SRSD AREA \n");
+ printk(KERN_INFO "SRSD dump_flags =%d\n", ph->kernel_data.dump_flags);
+ printk(KERN_INFO "SRSD source_type =%d\n", ph->kernel_data.source_type);
+ printk(KERN_INFO "SRSD error_flags =%d\n", ph->kernel_data.error_flags);
+ printk(KERN_INFO "SRSD source_address =%lx\n",
+ ph->kernel_data.source_address);
+ printk(KERN_INFO "SRSD source_length =%lx\n",
+ ph->kernel_data.source_length);
+ printk(KERN_INFO "SRSD length_copied =%lx\n",
+ ph->kernel_data.length_copied);
+#endif
+}
+
static void register_dump_area(struct phyp_dump_header *ph, unsigned long addr)
{
int rc;
@@ -136,9 +191,11 @@ static void register_dump_area(struct ph
1, ph, sizeof(struct phyp_dump_header));
} while (rtas_busy_delay(rc));
- if (rc)
+ if (rc) {
printk(KERN_ERR "phyp-dump: unexpected error (%d) on "
"register\n", rc);
+ print_dump_header(ph);
+ }
}
/* ------------------------------------------------- */
@@ -247,8 +304,8 @@ static int __init phyp_dump_setup(void)
of_node_put(rtas);
}
+ print_dump_header(dump_header);
dump_area_length = init_dump_header(&phdr);
-
/* align down */
dump_area_start = phyp_dump_info->init_reserve_start & PAGE_MASK;
^ permalink raw reply
* [PATCH 4/8] pseries: phyp dump: register dump area.
From: Manish Ahuja @ 2008-02-29 0:29 UTC (permalink / raw)
To: linuxppc-dev, paulus, michael; +Cc: mahuja, linasvepstas
In-Reply-To: <47C74A66.1060105@austin.ibm.com>
Set up the actual dump header, register it with the hypervisor.
Signed-off-by: Manish Ahuja <mahuja@us.ibm.com>
Signed-off-by: Linas Vepstas <linasvepstas@gmail.com>
------
arch/powerpc/platforms/pseries/phyp_dump.c | 137 +++++++++++++++++++++++++++--
1 file changed, 131 insertions(+), 6 deletions(-)
Index: 2.6.25-rc1/arch/powerpc/platforms/pseries/phyp_dump.c
===================================================================
--- 2.6.25-rc1.orig/arch/powerpc/platforms/pseries/phyp_dump.c 2008-02-28 23:36:01.000000000 -0600
+++ 2.6.25-rc1/arch/powerpc/platforms/pseries/phyp_dump.c 2008-02-28 23:36:42.000000000 -0600
@@ -30,6 +30,117 @@
static struct phyp_dump phyp_dump_global;
struct phyp_dump *phyp_dump_info = &phyp_dump_global;
+static int ibm_configure_kernel_dump;
+/* ------------------------------------------------- */
+/* RTAS interfaces to declare the dump regions */
+
+struct dump_section {
+ u32 dump_flags;
+ u16 source_type;
+ u16 error_flags;
+ u64 source_address;
+ u64 source_length;
+ u64 length_copied;
+ u64 destination_address;
+};
+
+struct phyp_dump_header {
+ u32 version;
+ u16 num_of_sections;
+ u16 status;
+
+ u32 first_offset_section;
+ u32 dump_disk_section;
+ u64 block_num_dd;
+ u64 num_of_blocks_dd;
+ u32 offset_dd;
+ u32 maxtime_to_auto;
+ /* No dump disk path string used */
+
+ struct dump_section cpu_data;
+ struct dump_section hpte_data;
+ struct dump_section kernel_data;
+};
+
+/* The dump header *must be* in low memory, so .bss it */
+static struct phyp_dump_header phdr;
+
+#define NUM_DUMP_SECTIONS 3
+#define DUMP_HEADER_VERSION 0x1
+#define DUMP_REQUEST_FLAG 0x1
+#define DUMP_SOURCE_CPU 0x0001
+#define DUMP_SOURCE_HPTE 0x0002
+#define DUMP_SOURCE_RMO 0x0011
+
+/**
+ * init_dump_header() - initialize the header declaring a dump
+ * Returns: length of dump save area.
+ *
+ * When the hypervisor saves crashed state, it needs to put
+ * it somewhere. The dump header tells the hypervisor where
+ * the data can be saved.
+ */
+static unsigned long init_dump_header(struct phyp_dump_header *ph)
+{
+ unsigned long addr_offset = 0;
+
+ /* Set up the dump header */
+ ph->version = DUMP_HEADER_VERSION;
+ ph->num_of_sections = NUM_DUMP_SECTIONS;
+ ph->status = 0;
+
+ ph->first_offset_section =
+ (u32)offsetof(struct phyp_dump_header, cpu_data);
+ ph->dump_disk_section = 0;
+ ph->block_num_dd = 0;
+ ph->num_of_blocks_dd = 0;
+ ph->offset_dd = 0;
+
+ ph->maxtime_to_auto = 0; /* disabled */
+
+ /* The first two sections are mandatory */
+ ph->cpu_data.dump_flags = DUMP_REQUEST_FLAG;
+ ph->cpu_data.source_type = DUMP_SOURCE_CPU;
+ ph->cpu_data.source_address = 0;
+ ph->cpu_data.source_length = phyp_dump_info->cpu_state_size;
+ ph->cpu_data.destination_address = addr_offset;
+ addr_offset += phyp_dump_info->cpu_state_size;
+
+ ph->hpte_data.dump_flags = DUMP_REQUEST_FLAG;
+ ph->hpte_data.source_type = DUMP_SOURCE_HPTE;
+ ph->hpte_data.source_address = 0;
+ ph->hpte_data.source_length = phyp_dump_info->hpte_region_size;
+ ph->hpte_data.destination_address = addr_offset;
+ addr_offset += phyp_dump_info->hpte_region_size;
+
+ /* This section describes the low kernel region */
+ ph->kernel_data.dump_flags = DUMP_REQUEST_FLAG;
+ ph->kernel_data.source_type = DUMP_SOURCE_RMO;
+ ph->kernel_data.source_address = PHYP_DUMP_RMR_START;
+ ph->kernel_data.source_length = PHYP_DUMP_RMR_END;
+ ph->kernel_data.destination_address = addr_offset;
+ addr_offset += ph->kernel_data.source_length;
+
+ return addr_offset;
+}
+
+static void register_dump_area(struct phyp_dump_header *ph, unsigned long addr)
+{
+ int rc;
+ ph->cpu_data.destination_address += addr;
+ ph->hpte_data.destination_address += addr;
+ ph->kernel_data.destination_address += addr;
+
+ do {
+ rc = rtas_call(ibm_configure_kernel_dump, 3, 1, NULL,
+ 1, ph, sizeof(struct phyp_dump_header));
+ } while (rtas_busy_delay(rc));
+
+ if (rc)
+ printk(KERN_ERR "phyp-dump: unexpected error (%d) on "
+ "register\n", rc);
+}
+
/* ------------------------------------------------- */
/**
* release_memory_range -- release memory previously lmb_reserved
@@ -108,7 +219,9 @@ static struct kobj_attribute rr = __ATTR
static int __init phyp_dump_setup(void)
{
struct device_node *rtas;
- const int *dump_header = NULL;
+ const struct phyp_dump_header *dump_header = NULL;
+ unsigned long dump_area_start;
+ unsigned long dump_area_length;
int header_len = 0;
int rc;
@@ -120,7 +233,13 @@ static int __init phyp_dump_setup(void)
if (!phyp_dump_info->phyp_dump_configured)
return -ENOSYS;
- /* Is there dump data waiting for us? */
+ /* Is there dump data waiting for us? If there isn't,
+ * then register a new dump area, and release all of
+ * the rest of the reserved ram.
+ *
+ * The /rtas/ibm,kernel-dump rtas node is present only
+ * if there is dump data waiting for us.
+ */
rtas = of_find_node_by_path("/rtas");
if (rtas) {
dump_header = of_get_property(rtas, "ibm,kernel-dump",
@@ -128,17 +247,23 @@ static int __init phyp_dump_setup(void)
of_node_put(rtas);
}
- if (dump_header == NULL)
+ dump_area_length = init_dump_header(&phdr);
+
+ /* align down */
+ dump_area_start = phyp_dump_info->init_reserve_start & PAGE_MASK;
+
+ if (dump_header == NULL) {
+ register_dump_area(&phdr, dump_area_start);
return 0;
+ }
/* Should we create a dump_subsys, analogous to s390/ipl.c ? */
rc = sysfs_create_file(kernel_kobj, &rr.attr);
- if (rc) {
+ if (rc)
printk(KERN_ERR "phyp-dump: unable to create sysfs file (%d)\n",
rc);
- return 0;
- }
+ /* ToDo: re-register the dump area, for next time. */
return 0;
}
machine_subsys_initcall(pseries, phyp_dump_setup);
^ 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