* [PATCH/RFC 1/6]: phyp dump: Documentation
From: Linas Vepstas @ 2007-11-21 22:37 UTC (permalink / raw)
To: linuxppc-dev; +Cc: mahuja, lkessler, strosake, mahuja
In-Reply-To: <20071121223639.GB4374@austin.ibm.com>
Basic documentation for hypervisor-assisted dump.
Signed-off-by: Linas Vepstas <linas@austin.ibm.com>
----
Documentation/powerpc/phyp-assisted-dump.txt | 126 +++++++++++++++++++++++++++
1 file changed, 126 insertions(+)
Index: linux-2.6.24-rc3-git1/Documentation/powerpc/phyp-assisted-dump.txt
===================================================================
--- /dev/null 1970-01-01 00:00:00.000000000 +0000
+++ linux-2.6.24-rc3-git1/Documentation/powerpc/phyp-assisted-dump.txt 2007-11-21 16:26:44.000000000 -0600
@@ -0,0 +1,126 @@
+
+ Hypervisor-Assisted Dump
+ ------------------------
+ November 2007
+
+The goal of hypervisor-assisted dump is to enable the dump of
+a crashed system, and to do so from a fully-reset system, and
+to minimize the total elapsed time until the system is back
+in production use.
+
+As compared to kdump or other strategies, hypervisor-assisted
+dump offers several strong, practical advantages:
+
+-- Unlike kdump, the system has been reset, and loaded
+ with a fresh copy of the kernel. In particular,
+ PCI and I/O devices have been reinitialized and are
+ in a clean, consistent state.
+-- As the dump is performed, the dumped memory becomes
+ immediately available to the system for normal use.
+-- After the dump is completed, no further reboots are
+ required; the system will be fully usable, and running
+ in it's normal, production mode on it normal kernel.
+
+The above can only be accomplished by coordination with,
+and assistance from the hypervisor. The procedure is
+as follows:
+
+-- When a system crashes, the hypervisor will save
+ the low 256MB of RAM to a previously registered
+ save region. It will also save system state, system
+ registers, and hardware PTE's.
+
+-- After the low 256MB area has been saved, the
+ hypervisor will reset PCI and other hardware state.
+ It will *not* clear RAM. It will then launch the
+ bootloader, as normal.
+
+-- The freshly booted kernel will notice that there
+ is a new node (ibm,dump-kernel) in the device tree,
+ indicating that there is crash data available from
+ a previous boot. It will boot into only 256MB of RAM,
+ reserving the rest of system memory.
+
+-- Userspace tools will read /proc/kcore to obtain the
+ contents of memory, which holds the previous crashed
+ kernel. The userspace tools may copy this info to
+ disk, or network, nas, san, iscsi, etc. as desired.
+
+-- As the userspace tools complete saving a portion of
+ dump, they echo an offset and size to
+ /sys/kernel/release_region to release the reserved
+ memory back to general use.
+
+ An example of this is:
+ "echo 0x40000000 0x10000000 > /sys/kernel/release_region"
+ which will release 256MB at the 1GB boundary.
+
+Please note that the hypervisor-assisted dump feature
+is only available on Power6-based systems with recent
+firmware versions.
+
+Implementation details:
+----------------------
+In order for this scheme to work, memory needs to be reserved
+quite early in the boot cycle. However, access to the device
+tree this early in the boot cycle is difficult, and device-tree
+access is needed to determine if there is a crash data waiting.
+To work around this problem, all but 256MB of RAM is reserved
+during early boot. A short while later in boot, a check is made
+to determine if there is dump data waiting. If there isn't,
+then the reserved memory is released to general kernel use.
+If there is dump data, then the /sys/kernel/release_region
+file is created, and the reserved memory is held.
+
+If there is no waiting dump data, then all but 256MB of the
+reserved ram will be released for general kernel use. The
+highest 256 MB of RAM will *not* be released: this region
+will be kept permanently reserved, so that it can act as
+a receptacle for a copy of the low 256MB in the case a crash
+does occur. See, however, "open issues" below, as to whether
+such a reserved region is really needed.
+
+General notes:
+--------------
+Security: please note that there are potential security issues
+with any sort of dump mechanism. In particular, plaintext
+(unencrypted) data, and possibly passwords, may be present in
+the dump data. Userspace tools must take adequate precautions to
+preserve security.
+
+Open issues:
+------------
+ o User-space dump tool integration is completely unresolved.
+
+ o The various code paths that tell the hypervisor that a crash
+ occurred, vs. it simply being a normal reboot, should be
+ reviewed, and possibly clarified/fixed.
+
+ o The real-virtual mapping is awkward and unaddressed. There
+ is currently no clear way of matching up the contents of
+ /proc/kcore to the values that need to be sent to
+ /sys/kernel/release_region
+
+ o Instead of using /sys/kernel, should there be a /sys/dump
+ instead? There is a dump_subsys being created by the s390 code,
+ perhaps the pseries code should use a similar layout as well.
+
+ o Saved system registers and HPTE tables will be located in high
+ memory. There is currently no way of telling user-space where
+ these are located.
+
+ o The post-dump procedures are incomplete. In particular,
+ after a dump as been taken, the system should re-register
+ with the hypervisor, so that a subsequent crash can be handled.
+
+ o The hypervisor may have an error preserving the dump data.
+ The current code does not check for this error, and does
+ not handle it.
+
+ o Is reserving a 256MB region really required? The goal of
+ reserving a 256MB scratch area is to make sure that no
+ important crash data is clobbered when the hypervisor
+ save low mem to the scratch area. But, if one could assure
+ that nothing important is located in some 256MB area, then
+ it would not need to be reserved.
+
^ permalink raw reply
* [PATCH/RFC 0/6]: phyp dump: hypervisor-assisted dump
From: Linas Vepstas @ 2007-11-21 22:36 UTC (permalink / raw)
To: linuxppc-dev; +Cc: mahuja, lkessler, strosake, mahuja
The following series of patches implement a basic framework
for hypervisor-assisted dump. The very first patch provides
documentation explaining what this is :-). Yes, its supposed
to be an improvement over kdump.
The patches mostly sort-of work; a list of open issues
is inculded in the documentation. It also appears that
the not-yet-released firmware versions this was tested
on are still, ahem, incomplete; this work is also pending.
-- Linas & Manish
^ permalink raw reply
* Re: [PATCH 3/3] [POWERPC] Add docs for Freescale DMA & DMA channel device tree nodes
From: David Gibson @ 2007-11-21 22:28 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, Timur Tabi
In-Reply-To: <47448687.6010106@freescale.com>
On Wed, Nov 21, 2007 at 01:27:03PM -0600, Scott Wood wrote:
> Kumar Gala wrote:
> > On Nov 21, 2007, at 11:35 AM, Scott Wood wrote:
> >> A cell-index property would be useful here for indexing into the summary
> >> status register.
> >
> > Divide by 0x80.
>
> :-P
>
> Using cell-index for things like this is reasonably common, and endorsed
> by current ePAPR drafts.
Indeed, indexing or writing into shared registers is exactly what
cell-index is for.
--
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: pseries (power3) boot hang (pageblock_nr_pages==0)
From: Mel Gorman @ 2007-11-21 22:03 UTC (permalink / raw)
To: Will Schmidt; +Cc: linuxppc-dev, Stephen Rothwell, Linux Memory Management List
In-Reply-To: <1195682111.4421.23.camel@farscape.rchland.ibm.com>
On (21/11/07 15:55), Will Schmidt didst pronounce:
> Hi Folks,
>
> I've been seeing a boot hang/crash on power3 systems for a few weeks.
> (hangs on a 270, drops to SP on a p610). This afternoon I got around
> to tracking it down to the changes in
>
> commit d9c2340052278d8eb2ffb16b0484f8f794def4de
> Do not depend on MAX_ORDER when grouping pages by mobility
>
> cpu 0x0: Vector: 100 (System Reset) at [c00000006e803ae0]
> pc: c00000000009bf50: .setup_per_zone_pages_min+0x298/0x34c
> lr: c00000000009be38: .setup_per_zone_pages_min+0x180/0x34c
> [c00000006e803e20] c0000000005e3898 .init_per_zone_pages_min+0x80/0xa0
> [c00000006e803ea0] c0000000005c9c04 .kernel_init+0x214/0x3d8
> [c00000006e803f90] c000000000026cac .kernel_thread+0x4c/0x68
>
> I narrowed it down to the for loop within setup_zone_migrate_reserve(),
> called by setup_per_zone_pages_min(). The loop spins forever due to
> pageblock_nr_pages being 0.
>
> I imagine this would be properly fixed with something similar to the
> change for iSeries.
Have you tried with the patch that fixed the iSeries boot problem?
Thanks for tracking down the problem to such a specific place.
Here it the iSeries fix in case it applies to this as well.
======
Ordinarily, the size of a pageblock is determined at compile-time based on
the hugepage size. On PPC64, the hugepage size is determined at runtime based
on what is supported by the machine. On legacy machines such as iSeries which
do not support hugepages, HPAGE_SHIFT is 0. This results in pageblock_order
being set to -PAGE_SHIFT and a crash results shortly afterwards.
This patch checks that HPAGE_SHIFT is a sensible value before using the
hugepage size. If it is 0, MAX_ORDER-1 is used instead as this is a sensible
value of pageblock_order.
This is a fix for 2.6.24.
Credit goes to Stephen Rothwell for identifying the bug and testing on
iSeries. Additional credit goes to David Gibson for testing with the
libhugetlbfs test suite.
Signed-off-by: Mel Gorman <mel@csn.ul.ie>
---
arch/powerpc/Kconfig | 5 +++++
mm/page_alloc.c | 11 ++++++++++-
2 files changed, 15 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 18f397c..232c298 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -187,6 +187,11 @@ config FORCE_MAX_ZONEORDER
default "9" if PPC_64K_PAGES
default "13"
+config HUGETLB_PAGE_SIZE_VARIABLE
+ bool
+ depends on HUGETLB_PAGE
+ default y
+
config MATH_EMULATION
bool "Math emulation"
depends on 4xx || 8xx || E200 || PPC_MPC832x || E500
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index da69d83..14e0ac3 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -3386,7 +3386,16 @@ static void __meminit free_area_init_core(struct pglist_data *pgdat,
if (!size)
continue;
- set_pageblock_order(HUGETLB_PAGE_ORDER);
+ /*
+ * If HPAGE_SHIFT is a sensible value, base the size of a
+ * pageblock on the hugepage size. Otherwise MAX_ORDER-1
+ * is a sensible choice
+ */
+ if (HPAGE_SHIFT > PAGE_SHIFT)
+ set_pageblock_order(HUGETLB_PAGE_ORDER);
+ else
+ set_pageblock_order(MAX_ORDER-1);
+
setup_usemap(pgdat, zone, size);
ret = init_currently_empty_zone(zone, zone_start_pfn,
size, MEMMAP_EARLY);
--
--
Mel Gorman
Part-time Phd Student Linux Technology Center
University of Limerick IBM Dublin Software Lab
^ permalink raw reply related
* pseries (power3) boot hang (pageblock_nr_pages==0)
From: Will Schmidt @ 2007-11-21 21:55 UTC (permalink / raw)
To: Mel Gorman, Stephen Rothwell, Linux Memory Management List,
linuxppc-dev
Hi Folks,
I've been seeing a boot hang/crash on power3 systems for a few weeks.
(hangs on a 270, drops to SP on a p610). This afternoon I got around
to tracking it down to the changes in
commit d9c2340052278d8eb2ffb16b0484f8f794def4de
Do not depend on MAX_ORDER when grouping pages by mobility
cpu 0x0: Vector: 100 (System Reset) at [c00000006e803ae0]
pc: c00000000009bf50: .setup_per_zone_pages_min+0x298/0x34c
lr: c00000000009be38: .setup_per_zone_pages_min+0x180/0x34c
[c00000006e803e20] c0000000005e3898 .init_per_zone_pages_min+0x80/0xa0
[c00000006e803ea0] c0000000005c9c04 .kernel_init+0x214/0x3d8
[c00000006e803f90] c000000000026cac .kernel_thread+0x4c/0x68
I narrowed it down to the for loop within setup_zone_migrate_reserve(),
called by setup_per_zone_pages_min(). The loop spins forever due to
pageblock_nr_pages being 0.
I imagine this would be properly fixed with something similar to the
change for iSeries. Depending on how obvious, quick and easy it is for
the experts to come up with a proper fix, I'll be able to do additional
debug and hacking after turkey-day. :-)
For the moment, I've hacked it with the following patch. (tested on
both the 270 and the p610):
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -2454,6 +2454,9 @@ static void setup_zone_migrate_reserve(struct zone
*zone)
reserve = roundup(zone->pages_min, pageblock_nr_pages) >>
pageblock_order;
+/* this is a cheap and dirty bailout, probally not a proper fix. */
+ if (pageblock_nr_pages==0) return;
+
for (pfn = start_pfn; pfn < end_pfn; pfn += pageblock_nr_pages)
{
if (!pfn_valid(pfn))
continue;
^ permalink raw reply
* Re: [PATCH] [POWERPC] Emulate isel (Integer Select) instruction
From: Kim Phillips @ 2007-11-21 21:48 UTC (permalink / raw)
To: Scott Wood; +Cc: Geert Uytterhoeven, linuxppc-dev, Paul Mackerras
In-Reply-To: <4744A5EC.1090201@freescale.com>
On Wed, 21 Nov 2007 15:41:00 -0600
Scott Wood <scottwood@freescale.com> wrote:
> Paul Mackerras wrote:
> > Geert Uytterhoeven writes:
> >
> >> +#define WARN_EMULATE(type) \
> >> + do { \
> >> + static unsigned int count; \
> >> + if (count++ < 10) \
> >> + pr_warning("%s used emulated %s instruction\n", \
> >> + current->comm, type); \
> >
> > Thinking about this a bit more, if an instruction gets emulated 10
> > times then I don't care, since it's probably only cost me 10
> > microseconds or so. If it gets emulated a million times then I might
> > want to look at it. So in fact this approach doesn't give me the
> > information I need to know whether there is a real problem or not.
>
> Maybe print the first time, then when it's happened 10 times, then 100,
> then 1000, etc.
>
or just use printk_ratelimit().
Kim
^ permalink raw reply
* Re: [PATCH] [POWERPC] Emulate isel (Integer Select) instruction
From: Scott Wood @ 2007-11-21 21:41 UTC (permalink / raw)
To: Paul Mackerras; +Cc: Geert Uytterhoeven, linuxppc-dev
In-Reply-To: <18244.42181.426804.662877@cargo.ozlabs.ibm.com>
Paul Mackerras wrote:
> Geert Uytterhoeven writes:
>
>> +#define WARN_EMULATE(type) \
>> + do { \
>> + static unsigned int count; \
>> + if (count++ < 10) \
>> + pr_warning("%s used emulated %s instruction\n", \
>> + current->comm, type); \
>
> Thinking about this a bit more, if an instruction gets emulated 10
> times then I don't care, since it's probably only cost me 10
> microseconds or so. If it gets emulated a million times then I might
> want to look at it. So in fact this approach doesn't give me the
> information I need to know whether there is a real problem or not.
Maybe print the first time, then when it's happened 10 times, then 100,
then 1000, etc.
-Scott
^ permalink raw reply
* Re: [PATCH] [POWERPC] Emulate isel (Integer Select) instruction
From: Paul Mackerras @ 2007-11-21 21:38 UTC (permalink / raw)
To: Geert Uytterhoeven; +Cc: linuxppc-dev
In-Reply-To: <Pine.LNX.4.62.0711211407260.12720@pademelon.sonytel.be>
Geert Uytterhoeven writes:
> Question: do we want it for emulate_single_step(), too?
No, because that's not emulating an instruction.
Paul.
^ permalink raw reply
* Re: [PATCH] [POWERPC] Emulate isel (Integer Select) instruction
From: Paul Mackerras @ 2007-11-21 21:36 UTC (permalink / raw)
To: Geert Uytterhoeven; +Cc: linuxppc-dev
In-Reply-To: <Pine.LNX.4.62.0711211407260.12720@pademelon.sonytel.be>
Geert Uytterhoeven writes:
> +#define WARN_EMULATE(type) \
> + do { \
> + static unsigned int count; \
> + if (count++ < 10) \
> + pr_warning("%s used emulated %s instruction\n", \
> + current->comm, type); \
Thinking about this a bit more, if an instruction gets emulated 10
times then I don't care, since it's probably only cost me 10
microseconds or so. If it gets emulated a million times then I might
want to look at it. So in fact this approach doesn't give me the
information I need to know whether there is a real problem or not.
Paul.
^ permalink raw reply
* Re: [PATCH] [POWERPC] Emulate isel (Integer Select) instruction
From: Paul Mackerras @ 2007-11-21 21:31 UTC (permalink / raw)
To: Geert Uytterhoeven; +Cc: linuxppc-dev
In-Reply-To: <Pine.LNX.4.62.0711211407260.12720@pademelon.sonytel.be>
Geert Uytterhoeven writes:
> @@ -721,31 +729,38 @@ static int emulate_instruction(struct pt
>
> /* Emulate the mfspr rD, PVR. */
> if ((instword & INST_MFSPR_PVR_MASK) == INST_MFSPR_PVR) {
> + WARN_EMULATE("mfpvr");
mfpvr is a bit different from the others in that it is actually a
privileged instruction, so I don't think it helps to warn about it.
Also, I think the warnings should be optional.
Paul.
^ permalink raw reply
* oops trying to execute sh
From: John Charles Tyner @ 2007-11-21 19:54 UTC (permalink / raw)
To: linuxppc-dev
I'm trying to boot linux 2.6.22.9 on an mpc860c rev d4.
When init trys to spawn sh, during the exec, the kernel oopses as seen
below:
## Starting application at 0x00400000 ...
loaded at: 00400000 004EF15C
board data at: 03F9FBC0 03F9FBFC
relocated to: 00404044 00404080
zimage at: 00404E74 004EC662
avail ram: 004F0000 04000000
Linux/PPC load: console=ttyCPM,38400
Uncompressing Linux...done.
Now booting the kernel
Linux version 2.6.22.9 (jtyner@johnnyedge) (gcc version 4.2.1) #113 Wed Nov 21 10:49:36 PST 2007
Zone PFN ranges:
DMA 0 -> 16384
Normal 16384 -> 16384
early_node_map[1] active PFN ranges
0: 0 -> 16384
Built 1 zonelists. Total pages: 16256
Kernel command line: console=ttyCPM,38400
PID hash table entries: 256 (order: 8, 1024 bytes)
Decrementer Frequency = 183750000/60
Console: colour dummy device 80x25
cpm_uart: console: compat mode
Dentry cache hash table entries: 8192 (order: 3, 32768 bytes)
Inode-cache hash table entries: 4096 (order: 2, 16384 bytes)
Memory: 63244k available (880k kernel code, 268k data, 444k init, 0k highmem)
Mount-cache hash table entries: 512
ADDSI: Init
io scheduler noop registered (default)
Serial: CPM driver $Revision: 0.02 $
ttyCPM0 at MMIO 0xc5000a80 (irq = 20) is a CPM UART
mice: PS/2 mouse device common for all mice
Freeing unused kernel memory: 444k init
init started: BusyBox v1.8.0 (2007-11-16 14:24:51 PST)
starting pid 103, tty '': '/bin/sh'
Oops: kernel access of bad area, sig: 11 [#1]
NIP: c0044ed0 LR: c0044ff0 CTR: 00000001
REGS: c3c0bd00 TRAP: 0300 Not tainted (2.6.22.9)
MSR: 00009032 <EE,ME,IR,DR> CR: 30099099 XER: a0008c7f
DAR: ff80103f, DSISR: c0000000
TASK = c0288070[103] 'init' THREAD: c3c0a000
GPR00: c0044ff0 c3c0bdb0 c0288070 ff800fff 00000000 7faf8000 00000000 00000000
GPR08: c01a8f58 c017d91c 00000002 c0179cd0 30099093 1007687c 00000002 c00f8744
GPR16: 00000000 c00f0a64 c011d1ac c00f0aa4 c00f0a90 c0120000 00000001 00000003
GPR24: c3c1ce00 00000000 c0180000 c0247550 00000000 c3c0bdc8 c0179cd0 ff800fff
NIP [c0044ed0] remove_vma+0x14/0x70
LR [c0044ff0] exit_mmap+0xc4/0xf0
Call Trace:
[c3c0bdb0] [c3c0bdc8] 0xc3c0bdc8 (unreliable)
[c3c0bdc0] [c0044ff0] exit_mmap+0xc4/0xf0
[c3c0bdf0] [c000f74c] mmput+0x50/0xd4
[c3c0be00] [c00591f4] flush_old_exec+0x3b8/0x7a8
[c3c0be50] [c0086cc0] load_elf_binary+0x2e8/0x1454
[c3c0bee0] [c005892c] search_binary_handler+0x58/0x12c
[c3c0bf00] [c0059d64] do_execve+0x13c/0x1f0
[c3c0bf20] [c00089b4] sys_execve+0x50/0x90
[c3c0bf40] [c0002a40] ret_from_syscall+0x0/0x38
Instruction dump:
7d808120 38210040 4e800020 83c30000 4bffff18 38a00000 4bffff9c 7c0802a6
9421fff0 bfc10008 90010014 7c7f1b78 <81230040> 83c3000c 2f890000 419e0018
The interesting thing is that r3 points to something funny. While tracing
this problem down, I replaced the remove_vma function with the following:
/*
* Close a vm structure and free it, returning the next.
*/
static struct vm_area_struct * __attribute__((__noinline__)) __remove_vma(struct vm_area_struct *vma)
{
struct vm_area_struct *next = vma->vm_next;
might_sleep();
if (vma->vm_ops && vma->vm_ops->close)
vma->vm_ops->close(vma);
if (vma->vm_file)
fput(vma->vm_file);
mpol_free(vma_policy(vma));
kmem_cache_free(vm_area_cachep, vma);
return next;
}
static struct vm_area_struct *remove_vma(struct vm_area_struct *vma)
{
asm volatile (
"lis 4,-128\n"
"ori 4,4,4095\n"
"tweq 3,4\n"
"lwz 5,0(1)\n"
"tweq 3,4\n"
);
return __remove_vma( vma );
}
With this code, the kernel oopses on the *second* tweq instruction:
Kernel BUG at c0045fd4 [verbose debug info unavailable]
Oops: Exception in kernel mode, sig: 5 [#1]
NIP: c0045fd4 LR: c00460a0 CTR: 00000001
REGS: c3c0bd10 TRAP: 0700 Not tainted (2.6.22.9)
MSR: 00029032 <EE,ME,IR,DR> CR: 30099099 XER: a0008c7f
TASK = c0292b40[103] 'init' THREAD: c3c0a000
GPR00: 00000001 c3c0bdc0 c0292b40 ff800fff ff800fff c3c0bdf0 00000000 00000000
GPR08: c0219398 c017d91c 00000002 c0179cd0 30099093 1007687c 00000002 c00f8744
GPR16: 00000000 c00f0a64 c011d1ac c00f0aa4 c00f0a90 c0120000 00000001 00000003
GPR24: c3c32e00 00000000 c0180000 c0247080 00000000 c3c0bdc8 c0179cd0 c017641c
NIP [c0045fd4] remove_vma+0x10/0x18
LR [c00460a0] exit_mmap+0xc4/0xf0
Call Trace:
[c3c0bdc0] [c0046074] exit_mmap+0x98/0xf0 (unreliable)
[c3c0bdf0] [c000f74c] mmput+0x50/0xd4
[c3c0be00] [c005920c] flush_old_exec+0x3b8/0x7a8
[c3c0be50] [c0086cd8] load_elf_binary+0x2e8/0x1454
[c3c0bee0] [c0058944] search_binary_handler+0x58/0x12c
[c3c0bf00] [c0059d7c] do_execve+0x13c/0x1f0
[c3c0bf20] [c00089b4] sys_execve+0x50/0x90
[c3c0bf40] [c0002a40] ret_from_syscall+0x0/0x38
Instruction dump:
7fe4fb78 4800a0ed 80010014 7fc3f378 7c0803a6 bbc10008 38210010 4e800020
3c80ff80 60840fff 7c832008 80a10000 <7c832008> 4bffff7c 7c0802a6 9421ffd0
The access of memory through r1 seems to corrupt r3, and always with the
same value. The problem isn't necessarily here, though. If I modify my
remove_vma function to cause and correct the problem (by saving r3 prior
to the memory access and restoring it afterwards), I just get the same
problem in some other part of the code, but the oops is always caused
because the base register for some memory access is set to ff800fff.
I applied a recent patch I found that corrects the address returned by
cpm_dpram_addr and its use in cpu_uart_cpm1.h, and I've created my own
platform setup file by copying the mpc866ads setup enough to get the
console uart (SMC1) to work.
If there is any other information I can or need to provide, let me
know. Any help would be greatly appreciated.
Thanks,
John
^ permalink raw reply
* [RFC] PPC: convert for(...) cycles into for_each... form
From: Cyrill Gorcunov @ 2007-11-21 20:09 UTC (permalink / raw)
To: PPCML; +Cc: Paul Mackerras, LKML
From: Cyrill Gorcunov <gorcunov@gmail.com>
This patch does convert cyclic calls to of_find_compatible_node()
and of_find_node_by_type() into appropriate macroses. It does reduce
code a bit.
Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com>
---
WARNING: I've no PowerPC to test it - please reiew the patch
closely. Thanks.
arch/powerpc/kernel/legacy_serial.c | 8 ++++----
arch/powerpc/platforms/82xx/pq2.c | 4 ++--
arch/powerpc/platforms/celleb/scc_sio.c | 5 ++---
arch/powerpc/platforms/powermac/low_i2c.c | 3 +--
arch/powerpc/sysdev/mv64x60_pci.c | 4 ++--
arch/powerpc/sysdev/mv64x60_udbg.c | 4 ++--
arch/powerpc/sysdev/uic.c | 17 +++++------------
7 files changed, 18 insertions(+), 27 deletions(-)
diff --git a/arch/powerpc/kernel/legacy_serial.c b/arch/powerpc/kernel/legacy_serial.c
index 4ed5887..b5dc646 100644
--- a/arch/powerpc/kernel/legacy_serial.c
+++ b/arch/powerpc/kernel/legacy_serial.c
@@ -307,7 +307,7 @@ void __init find_legacy_serial_ports(void)
}
/* First fill our array with SOC ports */
- for (np = NULL; (np = of_find_compatible_node(np, "serial", "ns16550")) != NULL;) {
+ for_each_compatible_node(np, "serial", "ns16550") {
struct device_node *soc = of_get_parent(np);
if (soc && !strcmp(soc->type, "soc")) {
index = add_legacy_soc_port(np, np);
@@ -318,7 +318,7 @@ void __init find_legacy_serial_ports(void)
}
/* First fill our array with ISA ports */
- for (np = NULL; (np = of_find_node_by_type(np, "serial"));) {
+ for_each_node_by_type(np, "serial") {
struct device_node *isa = of_get_parent(np);
if (isa && !strcmp(isa->name, "isa")) {
index = add_legacy_isa_port(np, isa);
@@ -329,7 +329,7 @@ void __init find_legacy_serial_ports(void)
}
/* First fill our array with tsi-bridge ports */
- for (np = NULL; (np = of_find_compatible_node(np, "serial", "ns16550")) != NULL;) {
+ for_each_compatible_node(np, "serial", "ns16550") {
struct device_node *tsi = of_get_parent(np);
if (tsi && !strcmp(tsi->type, "tsi-bridge")) {
index = add_legacy_soc_port(np, np);
@@ -340,7 +340,7 @@ void __init find_legacy_serial_ports(void)
}
/* First fill our array with opb bus ports */
- for (np = NULL; (np = of_find_compatible_node(np, "serial", "ns16550")) != NULL;) {
+ for_each_compatible_node(np, "serial", "ns16550") {
struct device_node *opb = of_get_parent(np);
if (opb && (!strcmp(opb->type, "opb") ||
of_device_is_compatible(opb, "ibm,opb"))) {
diff --git a/arch/powerpc/platforms/82xx/pq2.c b/arch/powerpc/platforms/82xx/pq2.c
index a497cba..9e74393 100644
--- a/arch/powerpc/platforms/82xx/pq2.c
+++ b/arch/powerpc/platforms/82xx/pq2.c
@@ -72,11 +72,11 @@ err:
void __init pq2_init_pci(void)
{
- struct device_node *np = NULL;
+ struct device_node *np;
ppc_md.pci_exclude_device = pq2_pci_exclude_device;
- while ((np = of_find_compatible_node(np, NULL, "fsl,pq2-pci")))
+ for_each_compatible_node(np, NULL, "fsl,pq2-pci")
pq2_pci_add_bridge(np);
}
#endif
diff --git a/arch/powerpc/platforms/celleb/scc_sio.c b/arch/powerpc/platforms/celleb/scc_sio.c
index 6100082..5e43bac 100644
--- a/arch/powerpc/platforms/celleb/scc_sio.c
+++ b/arch/powerpc/platforms/celleb/scc_sio.c
@@ -42,14 +42,13 @@ static struct {
static int __init txx9_serial_init(void)
{
extern int early_serial_txx9_setup(struct uart_port *port);
- struct device_node *node = NULL;
+ struct device_node *node;
int i;
struct uart_port req;
struct of_irq irq;
struct resource res;
- while ((node = of_find_compatible_node(node,
- "serial", "toshiba,sio-scc")) != NULL) {
+ for_each_compatible_node(node, "serial", "toshiba,sio-scc") {
for (i = 0; i < ARRAY_SIZE(txx9_scc_tab); i++) {
if (!(txx9_serial_bitmap & (1<<i)))
continue;
diff --git a/arch/powerpc/platforms/powermac/low_i2c.c b/arch/powerpc/platforms/powermac/low_i2c.c
index da2007e..864fbf4 100644
--- a/arch/powerpc/platforms/powermac/low_i2c.c
+++ b/arch/powerpc/platforms/powermac/low_i2c.c
@@ -585,8 +585,7 @@ static void __init kw_i2c_probe(void)
struct device_node *np, *child, *parent;
/* Probe keywest-i2c busses */
- for (np = NULL;
- (np = of_find_compatible_node(np, "i2c","keywest-i2c")) != NULL;){
+ for_each_compatible_node(np, "i2c","keywest-i2c") {
struct pmac_i2c_host_kw *host;
int multibus, chans, i;
diff --git a/arch/powerpc/sysdev/mv64x60_pci.c b/arch/powerpc/sysdev/mv64x60_pci.c
index 6933f9c..d21ab8f 100644
--- a/arch/powerpc/sysdev/mv64x60_pci.c
+++ b/arch/powerpc/sysdev/mv64x60_pci.c
@@ -164,8 +164,8 @@ static int __init mv64x60_add_bridge(struct device_node *dev)
void __init mv64x60_pci_init(void)
{
- struct device_node *np = NULL;
+ struct device_node *np;
- while ((np = of_find_compatible_node(np, "pci", "marvell,mv64x60-pci")))
+ for_each_compatible_node(np, "pci", "marvell,mv64x60-pci")
mv64x60_add_bridge(np);
}
diff --git a/arch/powerpc/sysdev/mv64x60_udbg.c b/arch/powerpc/sysdev/mv64x60_udbg.c
index 367e7b1..35c77c7 100644
--- a/arch/powerpc/sysdev/mv64x60_udbg.c
+++ b/arch/powerpc/sysdev/mv64x60_udbg.c
@@ -85,10 +85,10 @@ static void mv64x60_udbg_init(void)
if (!stdout)
return;
- for (np = NULL;
- (np = of_find_compatible_node(np, "serial", "marvell,mpsc")); )
+ for_each_compatible_node(np, "serial", "marvell,mpsc") {
if (np == stdout)
break;
+ }
of_node_put(stdout);
if (!np)
diff --git a/arch/powerpc/sysdev/uic.c b/arch/powerpc/sysdev/uic.c
index 5149716..815d6db 100644
--- a/arch/powerpc/sysdev/uic.c
+++ b/arch/powerpc/sysdev/uic.c
@@ -326,28 +326,23 @@ void __init uic_init_tree(void)
const u32 *interrupts;
/* First locate and initialize the top-level UIC */
-
- np = of_find_compatible_node(NULL, NULL, "ibm,uic");
- while (np) {
+ for_each_compatible_node(np, NULL, "ibm,uic") {
interrupts = of_get_property(np, "interrupts", NULL);
- if (! interrupts)
+ if (!interrupts)
break;
-
- np = of_find_compatible_node(np, NULL, "ibm,uic");
}
BUG_ON(!np); /* uic_init_tree() assumes there's a UIC as the
* top-level interrupt controller */
primary_uic = uic_init_one(np);
- if (! primary_uic)
+ if (!primary_uic)
panic("Unable to initialize primary UIC %s\n", np->full_name);
irq_set_default_host(primary_uic->irqhost);
of_node_put(np);
/* The scan again for cascaded UICs */
- np = of_find_compatible_node(NULL, NULL, "ibm,uic");
- while (np) {
+ for_each_compatible_node(np, NULL, "ibm,uic") {
interrupts = of_get_property(np, "interrupts", NULL);
if (interrupts) {
/* Secondary UIC */
@@ -355,7 +350,7 @@ void __init uic_init_tree(void)
int ret;
uic = uic_init_one(np);
- if (! uic)
+ if (!uic)
panic("Unable to initialize a secondary UIC %s\n",
np->full_name);
@@ -373,8 +368,6 @@ void __init uic_init_tree(void)
/* FIXME: setup critical cascade?? */
}
-
- np = of_find_compatible_node(np, NULL, "ibm,uic");
}
}
^ permalink raw reply related
* Re: [RFC/PATCH 5/14] powerpc: Fix 440/440A machine check handling
From: Benjamin Herrenschmidt @ 2007-11-21 20:05 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev
In-Reply-To: <20071121135109.73b9e98f@weaponx>
On Wed, 2007-11-21 at 13:51 -0600, Josh Boyer wrote:
> > Hrm... it's per processor, not per board. I didn't feel like digging
> > which board uses which processor and go fixup all the ppc_md's
>
> Sounds like something a generic function could probe for from the DTS.
> I'll look at doing something here when I start making 44x
> multiplatform
> (soon).
Well... we already probe the CPU type.... from cputable.
So if there was a place to put that, it would be the cputable.
Ben.
^ permalink raw reply
* [PATCH] PPC: fix missed increment on device interface counter
From: Cyrill Gorcunov @ 2007-11-21 19:56 UTC (permalink / raw)
To: Kumar Gala; +Cc: PPCML, LKML
From: Cyrill Gorcunov <gorcunov@gmail.com>
This patch adds simple increment on device interface counter
(it seems to be accidently missed)
Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com>
---
arch/powerpc/platforms/pasemi/electra_ide.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/platforms/pasemi/electra_ide.c b/arch/powerpc/platforms/pasemi/electra_ide.c
index 12fb0c9..8e73086 100644
--- a/arch/powerpc/platforms/pasemi/electra_ide.c
+++ b/arch/powerpc/platforms/pasemi/electra_ide.c
@@ -42,7 +42,7 @@ static int __devinit electra_ide_init(void)
np = of_find_compatible_node(NULL, "ide", "electra-ide");
i = 0;
- while (np && i < MAX_IFS) {
+ while (np && i++ < MAX_IFS) {
memset(r, 0, sizeof(r));
/* pata_platform wants two address ranges: one for the base registers,
^ permalink raw reply related
* Re: [PATCH 1/8] ibm_newemac: Fix possible lockup on close
From: Benjamin Herrenschmidt @ 2007-11-21 19:53 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: netdev, jgarzik, linuxppc-dev
In-Reply-To: <20071121154123.GB23589@lst.de>
On Wed, 2007-11-21 at 16:41 +0100, Christoph Hellwig wrote:
> On Wed, Nov 21, 2007 at 05:06:39PM +1100, Benjamin Herrenschmidt wrote:
> > It's a bad idea to call flush_scheduled_work from within a
> > netdev->stop because the linkwatch will occasionally take the
> > rtnl lock from a workqueue context, and thus that can deadlock.
> >
> > This reworks things a bit in that area to avoid the problem.
>
> So from the name of the driver you want to keep the previous emac
> driver around. Is there a good reason for that?
Until arch/ppc is gone... the previous driver works with arch/ppc the
new one with arch/powerpc.
If we kill arch/ppc in .25, then we'll remove the old driver and rename
the new one. If not, that will wait til .26
I'm hard at work porting as much of 4xx over I can to get to the point
where we -can- kill arch/ppc but I'm not done yet.
Cheers,
Ben.
^ permalink raw reply
* Re: [RFC/PATCH 0/14] powerpc: 4xx PCI and PCI-X support
From: Benjamin Herrenschmidt @ 2007-11-21 19:51 UTC (permalink / raw)
To: Stefan Roese; +Cc: linuxppc-dev
In-Reply-To: <200711211504.13003.sr@denx.de>
On Wed, 2007-11-21 at 15:04 +0100, Stefan Roese wrote:
> On Wednesday 21 November 2007, Josh Boyer wrote:
> > Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> > > Here's a set of patches that bring PCI and PCI-X support for
> > > 4xx (PCIe still missing) in arch/powerpc.
> > >
> > > This is for review before I ask paulus to pull that into his
> > > for 2.6.25 tree. Some of the patches still need a bit more
> > > testing vs. regressions on other platforms such as the
> > > 64 bits resource fixup one.
> >
> > I'm starting my 2.6.25 branch today. I'll probably throw these in
> > there after I've tested a bit, since I need them to make further
> > progress with 4xx anyway.
>
> Yes, it would be great to have an "official" repo with all the new 4xx stuff
> (PCI, EMAC...) stuff.
It would be good, but not in the form of a for-2.6.25 because some of
the patches aren't yet dry enough, more like something paulus could pull
into powerpc.git...
Ben.
^ permalink raw reply
* Re: [RFC/PATCH 0/14] powerpc: 4xx PCI and PCI-X support
From: Benjamin Herrenschmidt @ 2007-11-21 19:50 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev
In-Reply-To: <20071121072348.7fff79a9@weaponx>
On Wed, 2007-11-21 at 07:23 -0600, Josh Boyer wrote:
> On Wed, 21 Nov 2007 17:16:17 +1100
> Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
>
> > Here's a set of patches that bring PCI and PCI-X support for
> > 4xx (PCIe still missing) in arch/powerpc.
> >
> > This is for review before I ask paulus to pull that into his
> > for 2.6.25 tree. Some of the patches still need a bit more
> > testing vs. regressions on other platforms such as the
> > 64 bits resource fixup one.
>
> I'm starting my 2.6.25 branch today. I'll probably throw these in
> there after I've tested a bit, since I need them to make further
> progress with 4xx anyway.
Don't until I submit them for inclusion (when I said paulus above, I
actually meant you of course :-), I want one more round (I already have
enough comments to do minor fixups on most of them)
But I would definitely appreciate testing :-)
Cheers,
Ben.
^ permalink raw reply
* Re: [RFC/PATCH 5/14] powerpc: Fix 440/440A machine check handling
From: Josh Boyer @ 2007-11-21 19:51 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev
In-Reply-To: <1195674530.6970.86.camel@pasglop>
On Thu, 22 Nov 2007 06:48:50 +1100
Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
>
> > Why didn't you just add a ppc_md.machine_check_exception to the
> > effected boards? Then you could have gotten rid of the ifdefs all
> > together.
>
> Hrm... it's per processor, not per board. I didn't feel like digging
> which board uses which processor and go fixup all the ppc_md's
Sounds like something a generic function could probe for from the DTS.
I'll look at doing something here when I start making 44x multiplatform
(soon).
josh
^ permalink raw reply
* Re: [RFC/PATCH 13/14] powerpc: EP405 boards support for arch/powerpc
From: Benjamin Herrenschmidt @ 2007-11-21 19:49 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev
In-Reply-To: <20071121072151.01156349@weaponx>
>
> Hm... odd. I don't remember writing this device tree ;)
Heh, oops... it's mostly copied from walnut. I'll fix that up.
Ben.
^ permalink raw reply
* Re: [RFC/PATCH 5/14] powerpc: Fix 440/440A machine check handling
From: Benjamin Herrenschmidt @ 2007-11-21 19:48 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev
In-Reply-To: <20071121071240.141d2917@weaponx>
> Why didn't you just add a ppc_md.machine_check_exception to the
> effected boards? Then you could have gotten rid of the ifdefs all
> together.
Hrm... it's per processor, not per board. I didn't feel like digging
which board uses which processor and go fixup all the ppc_md's
Ben.
^ permalink raw reply
* Re: [PATCH 3/3] [POWERPC] Add docs for Freescale DMA & DMA channel device tree nodes
From: Scott Wood @ 2007-11-21 19:27 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, Timur Tabi
In-Reply-To: <8B189FFE-F45E-470C-87A0-E9FC61A1CF59@kernel.crashing.org>
Kumar Gala wrote:
> On Nov 21, 2007, at 11:35 AM, Scott Wood wrote:
>> A cell-index property would be useful here for indexing into the summary
>> status register.
>
> Divide by 0x80.
:-P
Using cell-index for things like this is reasonably common, and endorsed
by current ePAPR drafts.
>>>> dma@21300 {
>>>> #address-cells = <1>;
>>>> #size-cells = <1>;
>>>> compatible = "fsl,mpc8610-dma", "fsl,mpc8540-
>>>> dma";
>>>> --> device-id = <0>;
>>
>> I don't see any justification for having such a property in the parent
>> node,
>> though.
>
> huh?
Timur put device-id properties in both the parent and the channel nodes.
I was wondering why he did the former.
-Scott
^ permalink raw reply
* Re: [PATCH] [POWERPC] Emulate isel (Integer Select) instruction
From: Kumar Gala @ 2007-11-21 19:22 UTC (permalink / raw)
To: Geert Uytterhoeven; +Cc: linuxppc-dev
In-Reply-To: <Pine.LNX.4.62.0711211746180.12720@pademelon.sonytel.be>
On Nov 21, 2007, at 10:50 AM, Geert Uytterhoeven wrote:
> On Wed, 21 Nov 2007, Kumar Gala wrote:
>> On Nov 21, 2007, at 7:09 AM, Geert Uytterhoeven wrote:
>>> On Tue, 20 Nov 2007, Kumar Gala wrote:
>>>> On Nov 20, 2007, at 11:54 AM, Scott Wood wrote:
>>>>> Given that the instruction is meant to be a performance
>>>>> enhancement,
>>>>> we should probably warn the first few times it's emulated, so
>>>>> the user
>>>>> knows they should change their toolchain setup if possible.
>>>>
>>>> The same is true of mcrxr, popcntb, and possibly string ld/st.
>>>>
>>>> Feel free to submit a patch that warns about their usage.
>>
>> How about some per processor counters in sysfs under the processor.
>
> Per processor? That means it has to be per_cpu, which sounds a bit
> like
> overkill to me.
I can probably live with global, not sure that would work with sysfs.
- k
^ permalink raw reply
* Re: [PATCH 3/3] [POWERPC] Add docs for Freescale DMA & DMA channel device tree nodes
From: Kumar Gala @ 2007-11-21 19:21 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, Timur Tabi
In-Reply-To: <20071121173540.GC4413@loki.buserror.net>
On Nov 21, 2007, at 11:35 AM, Scott Wood wrote:
> On Wed, Nov 21, 2007 at 09:33:05AM -0600, Kumar Gala wrote:
>> On Nov 21, 2007, at 8:59 AM, Timur Tabi wrote:
>>>> + Example:
>>>> + dma@21000 {
>>>
>>> Shouldn't this be dma@21300?
>>
>> its an example that has not basis is reality :)
>
> But it should at least be internally consistent with this:
>
>>>> + reg = <21300 4>;
ahh, i see.. yes I'll fix that.
> [snip]
>>> The DMA controller and the DMA channels need a "device-id", so that
>>> they can be identified by number. Some peripherals, like the SSI,
>>> can only use the controller and channel number. This is what I have
>>> in my 8610 DTS:
>>
>> Why not use reg for this? I don't see any reason to add another
>> "unique id" when there is already one.
>
> A cell-index property would be useful here for indexing into the
> summary
> status register.
Divide by 0x80.
>>> dma@21300 {
>>> #address-cells = <1>;
>>> #size-cells = <1>;
>>> compatible = "fsl,mpc8610-dma", "fsl,mpc8540-
>>> dma";
>>> --> device-id = <0>;
>
> I don't see any justification for having such a property in the
> parent node,
> though.
huh?
- k
^ permalink raw reply
* Re: [PATCH 2/3] [POWERPC] Add docs for Freescale RapidIO device tree node
From: Kumar Gala @ 2007-11-21 19:20 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <20071121172927.GA4413@loki.buserror.net>
On Nov 21, 2007, at 11:29 AM, Scott Wood wrote:
> On Tue, Nov 20, 2007 at 11:13:58PM -0600, Kumar Gala wrote:
>> Required properties:
>> - compatible : compatible list, contains 2 entries,
>> first is
>> - "fsl,sata-CHIP", where CHIP is the processor
>> + "fsl,CHIP-sata", where CHIP is the processor
>> (mpc8315, mpc8379, etc.) and the second is
>> - "fsl,sata-pq2pro"
>> + "fsl,pq2pro-sata"
>> - interrupts : <interrupt mapping for SATA IRQ>
>> - interrupt-parent : optional, if needed for interrupt mapping
>> - reg : <registers mapping>
>> @@ -2531,12 +2531,53 @@ platforms are moved over to use the
>> flattened-device-tree model.
>> Example:
>>
>> sata@19000 {
>> - compatible = "fsl,mpc8315-sata", "fsl,sata-pq2pro;
>> + compatible = "fsl,mpc8315-sata", "fsl,pq2pro-sata;
>
> I think you meant to merge these changes with the previous patch...
Yeah a merge issue, I'll look into it.
- k
^ permalink raw reply
* Re: [PATCH 3/3] [POWERPC] Add docs for Freescale DMA & DMA channel device tree nodes
From: Kumar Gala @ 2007-11-21 19:19 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <20071121173308.GB4413@loki.buserror.net>
On Nov 21, 2007, at 11:33 AM, Scott Wood wrote:
> On Tue, Nov 20, 2007 at 11:14:40PM -0600, Kumar Gala wrote:
>> + - compatible : compatible list, contains 2 entries,
>> first is
>> + "fsl,CHIP-dma", where CHIP is the processor
>> + (mpc8540, mpc8540, etc.) and the second is
>> + "fsl,eloplus-dma"
>
> So if the DMA register set gets tweaked again, will we have
> eloplusplus? :-)
> Maybe elo2 would be better.
Seem unlikely for the forseeable future.
> Do we really need completely separate descriptions of the two, or
> can we just describe the difference in the compatible section?
it seemed easier to duplicate and fix.
- k
^ 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