-order
the strings from memory to match the endianess of the corresponding
16, 32, or 64 bit words. That would make the ASCII dump much less
useful.
Signed-off-by: Douglas Miller
---
arch/powerpc/xmon/xmon.c |7 ++-
1 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc
On 02/20/2017 11:01 PM, Michael Ellerman wrote:
Douglas Miller writes:
diff --git a/arch/powerpc/xmon/xmon.c b/arch/powerpc/xmon/xmon.c
index 9c0e17c..6249975 100644
--- a/arch/powerpc/xmon/xmon.c
+++ b/arch/powerpc/xmon/xmon.c
@@ -2334,9 +2338,49 @@ static void dump_pacas(void)
}
#endif
d8 dump 64 bit values
Signed-off-by: Douglas Miller
---
arch/powerpc/xmon/xmon.c | 65 +++--
1 files changed, 62 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/xmon/xmon.c b/arch/powerpc/xmon/xmon.c
index 9c0e17c..6249975 100644
--- a/ar
On 02/06/2017 07:50 AM, Douglas Miller wrote:
Hi Michael,
Yes, your patch seems a more complete solution. The idea of "d1",
"d2", "d4", and "d8" commands is more what I needed and makes more
sense to someone hitting xmon "cold". I'll work
tion on these sorts of patches (PPC only), do we submit initially to
upstream, or here on this (PPC) mailing list? It would be nice to get
this into the distros as soon as possible.
Thanks,
Doug
On 02/03/2017 04:31 AM, Michael Ellerman wrote:
Douglas Miller writes:
I'm referring to
gers. Maybe the original intent was only to simply output bytes of
memory, but to me the help implies otherwise and certainly something
more is needed.
I'll take a look at Balbir's patch and see if I can help move it along.
Thanks,
Doug
On 02/02/2017 07:46 PM, Michael Ellerman wrote:
Do
I was hoping this would be any easy fix, but now it looks like it will
be more difficult.
The basic problem is that xmon memory commands like 'dd' do not properly
display the data on LE instances. This means that not only is it
difficult to read but one cannot copy-paste addresses from the ou
trict about this and produces an EEH when "read"
permission is not and reading happens.
This adds a workaround in IODA code to always add the "read" bit when
the "write" bit is set.
Cc: Benjamin Herrenschmidt
Signed-off-by: Alexey Kardashevskiy
Tested-by: Douglas Miller
Tested-by: Douglas Miller
On 01/11/2016 10:40 PM, Alexey Kardashevskiy wrote:
Quite often drivers set only "write" permission assuming that this
includes "read" permission as well and this works on plenty platforms.
However IODA2 is strict about this and produces an EEH wh
37 PM, Alexey Kardashevskiy wrote:
On 01/20/2016 06:01 AM, Douglas Miller wrote:
On 01/18/2016 09:52 PM, Alexey Kardashevskiy wrote:
On 01/13/2016 01:24 PM, Douglas Miller wrote:
On 01/12/2016 05:07 PM, Benjamin Herrenschmidt wrote:
On Tue, 2016-01-12 at 15:40 +1100, Alexey Kardashevskiy wrote:
That looks fine to me.
Thanks!
On 02/09/2016 04:58 AM, Michael Ellerman wrote:
On Mon, 2015-23-11 at 15:01:15 UTC, Douglas Miller wrote:
Add 'P' command with optional task_struct address to dump all/one task's
information: task pointer, kernel stack pointer, PID, PPID, sta
On 01/18/2016 09:52 PM, Alexey Kardashevskiy wrote:
On 01/13/2016 01:24 PM, Douglas Miller wrote:
On 01/12/2016 05:07 PM, Benjamin Herrenschmidt wrote:
On Tue, 2016-01-12 at 15:40 +1100, Alexey Kardashevskiy wrote:
Quite often drivers set only "write" permission assuming
On 01/12/2016 05:07 PM, Benjamin Herrenschmidt wrote:
On Tue, 2016-01-12 at 15:40 +1100, Alexey Kardashevskiy wrote:
Quite often drivers set only "write" permission assuming that this
includes "read" permission as well and this works on plenty
platforms.
However IODA2 is strict about this and
Add 'P' command with optional task_struct address to dump all/one task's
information: task pointer, kernel stack pointer, PID, PPID, state
(interpreted), CPU where (last) running, and command.
Introduce XMON_PROTECT macro to standardize memory-access-fault
protection (setjm
ially used only by the 'P' command.
Signed-off-by: Douglas Miller
---
arch/powerpc/xmon/xmon.c | 63 ++
1 files changed, 63 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/xmon/xmon.c b/arch/powerpc/xmon/xmon.c
index 13c6e20..
Signed-off-by: Douglas Miller
---
arch/powerpc/xmon/xmon.c | 58 ++
1 files changed, 58 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/xmon/xmon.c b/arch/powerpc/xmon/xmon.c
index 13c6e20..5c24f55 100644
--- a/arch/powerpc/xmon/xmon.c
+++ b
Resending with Signed-Off line.
Request for comments
Add a command to xmon that prints basic task information like
ps(1) but includes the kernel stack pointer for use with 't'
(traceback) command.
Adds a macro to be used to wrap memory access with setjmp code
to protect against memory faults.
I
Request for comments
Add a command to xmon that prints basic task information like
ps(1) but includes the kernel stack pointer for use with 't'
(traceback) command.
Adds a macro to be used to wrap memory access with setjmp code
to protect against memory faults.
Is additional locking required? An
---
arch/powerpc/xmon/xmon.c | 58 ++
1 files changed, 58 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/xmon/xmon.c b/arch/powerpc/xmon/xmon.c
index 13c6e20..5c24f55 100644
--- a/arch/powerpc/xmon/xmon.c
+++ b/arch/powerpc/xmon/xmon.c
@@ -14
uct and it also
errored out cleanly. Of course, random memory might not always cause a
fault but rather just print garbage.
Thanks,
Doug
On 11/11/2015 02:09 AM, Benjamin Herrenschmidt wrote:
On Tue, 2015-11-10 at 10:50 -0600, Douglas Miller wrote:
+{
+ unsigned long tskv;
+ struct t
Sorry, rookie mistake: last minute changes without checking compile.
Here's is the corrected patch.
On 11/10/2015 09:31 AM, Douglas Miller wrote:
RFC: Not sure if I need locking when accessing task structs from xmon.
Please comment.
I found this new xmon command indispensable
this patch ready.
Thanks,
Doug
>From 5f2dd7c955443332835de86cfde2097e298fc657 Mon Sep 17 00:00:00 2001
From: Douglas Miller
Date: Thu, 5 Nov 2015 07:55:33 -0600
Subject: [PATCH] Add xmon command to dump process/task similar to ps(1)
---
arch/powerpc/xmon/xmon.c | 37 +++
22 matches
Mail list logo
