t;sched_clock_base_cc" to "tod_clock_base".
This commit is currently on the s390 features branch and will be integrated
in linux 4.14:
https://git.kernel.org/pub/scm/linux/kernel/git/s390/linux.git/commit/?h=features&id=6e2ef5e4f6cc57344762932d70d38ba4ec65fa8b
Cc: Martin Schwidefs
b8e0c80 2e383200000 1 7fffc00
The first entry e.g. "PTE: 0002e3df7060" is the physical address
of the entry in the table. The second, e.g. "=> 0002e383203d" is the
content of the entry itself (address and flags).
Reviewed-by:
the stack
base instead.
Without the patch the stack backtrace for running tasks (bt -a) can be
incomplete.
Signed-off-by: Michael Holzheu
---
s390x.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/s390x.c b/s390x.c
index 8e9cafa..e13bd59 100644
--- a/s390x.c
+++ b/s390x.c
/sda1: may be truncated or incomplete
PT_LOAD p_offset: 16384
p_filesz: 5497558138880
bytes required: 5497558155264
dumpfile size: 0
Fix this and print the following info message for block devices:
NOTE: /dev/sda1: No dump complete check for block devices
Signed-off-by: Michael Holzheu
> > #1 [00c1fe90] cpu_startup_entry at 180430
> > > > #2 [00c1fee8] start_kernel at d1fb10
> > > > #3 [00c1ff60] _stext at 100020
> > > >
> > > >
> > > > >
> > > > > And if so, I'm thinking that since
2 [00c1fee8] start_kernel at d1fb10
> > #3 [00c1ff60] _stext at 100020
> >
> >
> > >
> > > And if so, I'm thinking that since s390x will have set LIVE_DUMP
> > > flag set, if get_dumpfile_panic_task() returns NO_TASK, then
> > > panic_search
On Mon, 3 Aug 2015 13:16:19 -0400 (EDT)
Dave Anderson wrote:
>
>
> - Original Message -
> > On Mon, 03 Aug 2015 12:30:22 -0400
> > Dave Anderson wrote:
> >
> > >
> > >
> > > Ah, it must be because of the common user-kernel virtual address space on
> > > s390x?
> >
> > Yes we ha
if it's a live dump, which will just default to the idle task on
> cpu 0.
Although it does not solve the above problem it makes sense for
live dumps. What about the following patch?
---
crash: do not search panic tasks for live dumps
Always return "NO_TASK" if
On Tue, 4 Aug 2015 09:06:47 -0400 (EDT)
Dave Anderson wrote:
>
>
> - Original Message -
> > On Mon, 3 Aug 2015 14:54:28 -0400 (EDT)
> > Dave Anderson wrote:
> >
> > >
> > >
> > > - Original Message -
> > > > Hello Dave,
> > > >
> > > > On s390 (kernel 4.2.0-rc2) the "RSS" f
On Mon, 3 Aug 2015 14:54:28 -0400 (EDT)
Dave Anderson wrote:
>
>
> - Original Message -
> > Hello Dave,
> >
> > On s390 (kernel 4.2.0-rc2) the "RSS" field in "ps" is wrong.
> >
> > The reason is that in rss_page_types_init() enumerator_value("MM_ANONPAGES",
> > &anonpages) returns zer
On Mon, 03 Aug 2015 12:30:22 -0400
Dave Anderson wrote:
>
>
> Ah, it must be because of the common user-kernel virtual address space on
> s390x?
Yes we have overlapping virtual address ranges for kernel and user space and
user
space registers are stored at the start of the kernel stack.
Hi Dave,
I got a dump where a process "gmain" was incorrectly marked as running:
crash> ps | grep gmain
> 217 1 5 8bec23420 IN 0.0 463276 18240 gmain
The reason was that the "brute force" way parsing the "bt -t -o"
output in panic_search() found the symbol "panic" on the s
Hello Dave,
On s390 (kernel 4.2.0-rc2) the "RSS" field in "ps" is wrong.
The reason is that in rss_page_types_init() enumerator_value("MM_ANONPAGES",
&anonpages) returns zero for "anonpages" and therefore we add MM_FILEPAGES
twice instead of adding MM_ANONPAGES.
Example: Process that allocated 5
Hi Dave,
I recently looked into a linux 4.0 dump where the "ps" command prints "??"
for the state field of several tasks:
crash> ps
741660 1 7b408000 ?? 0.02152 2592 chcpu
748 2 24 20c284f00 IN 0.0 0 0 [migration/24]
752 2 22
fsets") the stack
> > frame overhead is already subtracted from the addresses. Therefore we
> > have to roundup the stack address to PAGE_SIZE.
> >
> > Signed-off-by: Michael Holzheu
>
> Hi Michael,
>
> For the changelog -- what's the symptom of the fai
fortunately we don't get the exact address because
since commit dc7ee00d477 ("s390: lowcore stack pointer offsets") the stack
frame overhead is already subtracted from the addresses. Therefore we
have to roundup the stack address to PAGE_SIZE.
Signed-off-by: Michael Holzheu
---
s39
On Wed, 20 May 2015 12:59:22 -0400 (EDT)
Dave Anderson wrote:
>
>
> - Original Message -
> > Hello Dave,
> >
> > At least on s390 the latest crash version 7.1 does not work with kernels >=
> > 4.0:
> >
> > WARNING: kernels compiled by different gcc versions:
> >/boot/vmlinux: (un
Hello Dave,
At least on s390 the latest crash version 7.1 does not work with kernels >= 4.0:
WARNING: kernels compiled by different gcc versions:
/boot/vmlinux: (unknown)
vmcore kernel: 4.9.2
WARNING: kernel version inconsistency between vmlinux and dumpfile
crash: incompatible argumen
0x
0x0000 0x
0x 0x
0x 0x
Signed-off-by: Michael Holzheu
---
defs.h|1
help.c|1
kernel.c |5 +--
netdump.c |6 +++
netdump
0x
0x 0x
0x 0x
0x 0x
0x 0x
0x 0x
0x 0x0000
Signed-off-by: Micha
Hello Dave,
For some reason the following posting did not arrive at the crash
mailing list:
https://www.sourceware.org/ml/gdb/2014-10/msg00061.html
https://www.sourceware.org/ml/gdb/2014-10/msg00062.html
Any idea why?
Michael
On Thu, 2 Oct 2014 10:27:00 +0200
Petr Tesarik wrote:
> On Thu, 2
comparator correctly.
Signed-off-by: Michael Holzheu
---
s390x.c | 14 --
1 file changed, 8 insertions(+), 6 deletions(-)
--- a/s390x.c
+++ b/s390x.c
@@ -1343,14 +1343,16 @@ s390x_print_lowcore(char* lc, struct bt_
fprintf(fp," -prefix : %#010lx\n", tmp[0]);
On Fri, 14 Feb 2014 12:12:46 -0500 (EST)
Dave Anderson wrote:
>
> Download from: http://people.redhat.com/anderson
> or
>https://github.com/crash-utility/crash/releases
Hello Dave,
Thanks for the repository!
Is it by intention that the tarball from
https://gi
Hello Dave,
For s390(x) in the near future kernels can have more than 64 CPUs. So
change the defines in "defs.h" accordingly.
Signed-off-by: Michael Holzheu
---
defs.h |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/defs.h
+++ b/defs.h
@@ -125,10 +125,10 @@
#defi
: Michael Holzheu
---
s390x.c |5 -
1 file changed, 4 insertions(+), 1 deletion(-)
--- a/s390x.c
+++ b/s390x.c
@@ -590,9 +590,12 @@ static int swap_entry(ulong entry)
if (THIS_KERNEL_VERSION < LINUX(2,6,19)) {
if ((entry & 0x601ULL) == 0
async_stack to find out the
location of the per-cpu stacks. With the above kernel change this is
no longer correct. For newer kernels with the "pcpu_devices" array
there is a second location where the stacks are stored. With this
patch we use the new location if available.
Signed-off-by:
On Tue, 5 Mar 2013 23:09:34 +
"Ku, Eugene" wrote:
> I tried again using kerntypes and it failed with a different error.
>
> # /RedHat/crash-6.1.0-X86/crash vmlinux-2.6.5-7.321-bigsmp
> dump-pts02504 Kerntypes-2.6.5-7.321-bigsmp ...
> crash: cannot resolve "_stext"
I think years ago we built
Hello Dave,
The following kernel commit changes the member "rq" to member
"root_rl" in the request_queue structure:
commit a051661ca6d134c18599498b185b667859d4339b
Author: Tejun Heo
Date: Tue Jun 26 15:05:44 2012 -0700
blkcg: implement per-blkg request allocation
- struct request_lis
Hi Dave,
On Fri, 16 Nov 2012 11:13:03 -0500 (EST)
Dave Anderson wrote:
>
> Hi Michael,
>
> I've queued this for crash-6.1.1, but can you confirm that
> there will not be any backwards-compatibility issues here?
Yes, I can confirm that this change does not break older kernels.
Michael
--
Cra
Hi Dave,
s390x: Allow HW Change-bit override for page table entries
The HW Change-bit override (0x100) is used now for s390x. This patch allows
page table entries that have set this bit.
Signed-off-by: Michael Holzheu
---
s390x.c |7 +++
1 file changed, 3 insertions(+), 4 deletions
Hi Dave,
On Thu, 25 Oct 2012 15:00:58 -0400 (EDT)
Dave Anderson wrote:
[..]
> This patch work for you?
>
> --- kernel.c 15 Oct 2012 19:05:39 - 1.286
> +++ kernel.c 25 Oct 2012 18:48:59 -
> @@ -4166,8 +4166,14 @@
> fprintf(fp, buf);
> }
>
> - for (i = 0,
Hi Dave,
Currently the log command does not print '\n' and '\t'. The reason
is that isprint() does not return true for those characters.
This patch adds the isspace() test in order to print these characters
properly.
Michael
---
kernel.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Hi Dave,
On s390 the new zEC12 machines support 2GB frames. In order to walk page tables
correctly add support to the page table walker function so it detects
2GB frames.
Michael
Signed-off-by: Heiko Carstens
Signed-off-by: Michael Holzheu
---
s390x.c |8
1 file changed, 8
Hello Dave,
In future s390/s390x Linux kernels struct "_lowcore" will be renamed
to "lowcore". This patch checks which struct is defined and uses the
correct one.
Michael
---
s390.c | 33 +
s390x.c | 36 +++-
2 files changed, 4
Hello Dave,
Currently on s390 the check for live dumps is called in s390x_init(POST_INIT).
Unfortunately this code is not executed when the "--minimal" command line
option is specified. Therefore when using this option, "help -p" does not
show the correct information for flags2.
This patch moves
Hello Alex,
On Wed, 01 Aug 2012 18:06:51 -0400
Alex Sidorenko wrote:
> On July 26, 2012 11:57:05 AM Petr Tesarik wrote:
> > Hi all,
> >
> > as part of SUSE HackWeek8, David started work on a GUI extension
> > using Qt4, which is a C++ project.
>
> Hi all,
>
> I have a working prototype (still
Hi Dave,
On Thu, 14 Jun 2012 15:45:55 -0400 (EDT)
Dave Anderson wrote:
[snip]
>
> So I suppose we *could* have a new crash "block" environment variable,
> settable with the "set" command, and then while it's in play you would
> see stuff based upon that particular scope. Hmmm...
>
> I just w
Hi Dave,
On Wed, 02 May 2012 09:21:57 -0400 (EDT)
Dave Anderson wrote:
>
> - Original Message -
>
> > >
> > > And that's because when a "machdep->uvtop()" operation is done on
> > > a user page that is not resident, the machine-dependent function
> > > should return FALSE -- but it sho
Hi Dave,
On Tue, 01 May 2012 15:24:17 -0400 (EDT)
Dave Anderson wrote:
> With respect to the 3rd "vm -p" bug, I did some cursory debugging, and
> here's what I found.
>
> In all cases, the readmem() failure occurs in
> _kl_pg_table_deref_s390x() as a result of transitioning from one page
> of P
Hi Dave,
Currently when we find a userspace pt_regs at the beginning of the stack,
we print nothing. With this patch the userspace PSW and general purpose
registers are printed.
With this change for the user it is clearer now that the task has
been interrupted while running in userspace.
Example
Hello Dave,
On Mon, 23 Apr 2012 08:50:02 -0400 (EDT)
Dave Anderson wrote:
[snip]
>
>
> Question: how does that code path ever get run?
Interesting...
I only tested the patch on a live dump and not on the live system
with /dev/mem. Therefore I did not see that. On a live system, as you
des
Hi Dave,
On Fri, 20 Apr 2012 10:03:23 -0400 (EDT)
Dave Anderson wrote:
> > Sounds good. So what about introducing a new macro LIVE() that
> > indicates that the dump or live system is inconsistent.
>
> Good idea -- queued for crash-6.0.6.
There is another ACTIVE() call in s390x.c that should b
Hi Dave,
On Fri, 20 Apr 2012 10:03:23 -0400 (EDT)
Dave Anderson wrote:
> - Original Message -
> > Hello Dave,
> >
> > On Thu, 19 Apr 2012 14:44:43 -0400 (EDT)
> > Dave Anderson wrote:
> >
> > [snip]
> >
> > > I would have no problem with adding a new LIVE_DUMP flag to
> > > pc->flags
Hello Dave,
On Thu, 19 Apr 2012 14:44:43 -0400 (EDT)
Dave Anderson wrote:
[snip]
> I would have no problem with adding a new LIVE_DUMP flag to
> pc->flags2, and just checking it in display_sys_stats() and
> non_matching_kernel() as you've done below. In dealing with
> dumpfiles generated from
Hi Dave,
On s390 we will have a dump method that creates live dumps, similar to
the snap.so crash plugin. Because Linux is not stopped while the dump
is created, the resulting dump is not consistent. Therefore it is
important that the crash tool informs the user about this issue.
The dump tool wr
Hi Petr,
On Mon, 2012-04-16 at 10:31 +0200, Petr Tesarik wrote:
> Hi Michael,
>
> I'm not a z/Series guru, but it seems to me that the address should not be
> returned directly, but rather assigned to the phys_addr output parameter.
The fix looks good, thanks! Dave could you please add the patc
Hi Dave,
On Thu, 2012-02-16 at 10:59 -0500, Dave Anderson wrote:
> Also, printf() is never used by the crash utility. (well, except
> by some dead va_server.c code, some dead remote.c debug code,
> and a couple places in s390dbf.c which I don't control...)
Probably I should change that in s390dbf
Hi Dave,
Currently the hex_ascii view displays also non ASCII characters. Example:
$ s390dbf test hex_ascii
00 01328703733:110640 1 - 01 00114288 fb 63 ff fb fc | �c���
To make the output better readable we should only print ASCII characters.
Signed-off-by: Michael Holzheu
Hi Dave,
On Thu, 2012-01-26 at 08:54 -0500, Dave Anderson wrote:
[snip]
> >
> > Any idea what's wrong here?
> >
> > Best Regards
> >
> > Michael
>
> Bob does:
>
> [Crash-utility] "zero-size memory allocation!" is back for Linux 3.1
> https://www.redhat.com/archives/crash-utility/2012-Ja
Hello Dave,
I have a s390x dump of a Linux-3.1 kernel where I get the error message:
crash: zero-size memory allocation! (called from 8009f504)
The error comes from max_cpudata_limit() where GETBUF fails:
/*
* Check the shared list of all the nodes.
*/
start_a
Hello Dave,
On Thu, 2012-01-19 at 10:56 -0500, Dave Anderson wrote:
> I have verified and applied the "irq -a" and "irq -s" options
> on both IA64 and PPC64.
>
> Both S390 and S390X do not support the "irq" command, so I'll defer
> all IR
Hi Dave,
On Mon, 2012-01-09 at 14:06 -0500, Dave Anderson wrote:
[snip]
> >
> > crash> struct page.lru
> > struct: invalid data structure reference: page.lru
> >
> > Any idea why we do not get the offset from gdb?
> > Perhaps a problem with the anonymous union?
>
> Right -- it's due to commit
Hello Dave,
When issuing "kmem -s" with crash 6.0.2 (same with 6.0.0) on a s390x
linux-3.2 kernel dump, I get the following:
...
1ff0a600 signal_cache1104112 150 632k
1ff0a540 sighand_cache 2088 8298 732k
kmem:
Hi Dave & Mahesh,
On Thu, 2011-12-22 at 11:05 -0500, Dave Anderson wrote:
> Download from: http://people.redhat.com/anderson
>
> Changelog:
>
> - Preparation for new s390x kernels that will increase MAX_PHYSMEM_BITS
>from 42 to 46.
>(mah...@linux.vnet.ibm.com, holz...@linux.vnet.ibm.co
Hi Dave,
On Thu, 2011-12-22 at 09:19 -0500, Dave Anderson wrote:
>
> - Original Message -
> >
> > Unfortunately Mahesh is currently not online. We still have some time
> > because Martin's kernel patch that introduces the change will go into
> > Linux version 3.3.
> >
> > So perhaps you
Hi Dave,
On Thu, 2011-12-22 at 08:47 -0500, Dave Anderson wrote:
>
> - Original Message -
> > Hello Dave and Mahesh,
> >
> > We also tried to solve the problem and came up with an alternative
> > solution.
> >
> > The function s390x_max_physmem_bits() solves the following equation:
> >
Hello Dave and Mahesh,
We also tried to solve the problem and came up with an alternative solution.
The function s390x_max_physmem_bits() solves the following equation:
array_len == NR_MEM_SECTIONS / SECTIONS_PER_ROOT
2^(MAX_PYSMEM_BITS - SECTION_SIZE_BITS)
Hello Mahesh, Dave,
I am no expert on memory management, but...
Mahesh Jagannath Salgaonkar wrote on 12/22/2011
10:06:43:
> > And complicating matters even further, your patch presumes that the
> > kernel has configured CONFIG_SPARSEMEM_EXTREME in conjunction with
> > CONFIG_SPARSEMEM. Would it
-off-by: Michael Holzheu
---
s390x.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/s390x.c
+++ b/s390x.c
@@ -1196,7 +1196,7 @@ s390x_print_lowcore(char* lc, struct bt_
fprintf(fp," %#018lx %#018lx\n", tmp[2],tmp[3]);
ptr = lc + MEMBER_OFFSET
fallback that
gets the CPU register information out of memory (see s390x_get_lowcore).
So for s390 it would be better that we only get a warning, when crash
does not find CPU information in a makedumpfile generated dump.
Signed-off-by: Michael Holzheu
---
diskdump.c |5 -
1 file changed
Hello Dave,
On Tue, 2011-09-20 at 12:09 -0400, Dave Anderson wrote:
> > > Or is there any other way that the panic'ing task can be ascertained from
> > > "S390D" dumpfiles such that get_dumpfile_panic_task() can do the job?
> >
> > Hmmm, I don't think so. Probably the only way is to search die or
Hello Dave,
On Mon, 2011-09-19 at 11:05 -0400, Dave Anderson wrote:
> > WARNING: multiple active tasks have called die and/or panic
> > WARNING: multiple active tasks have called die
> >
> > In task.c we call "foreach bt -t" and check if we find "die" on the stack.
> > When
> > doing this on s39
9ca7fa40] die at 100ee6
[9ca7fa90] die at 100f26
The current code then assumes that multiple tasks have called die().
This patch fixes this problem by an additional check that allows multiple
occurrences of the die() call on the stack (with bt -t) for one task.
Signed-off-by: Micha
Hello Dave,
On Thu, 2011-09-15 at 11:24 -0400, Dave Anderson wrote:
> Hi Michael,
>
> The "ULONG(ptr + 8)" below doesn't seem right:
You are right of course, thanks! At least I did the error
consistently :-)
>
> > --- a/s390.c
> > +++ b/s390.c
> > @@ -861,16 +861,16 @@ s390_print_lowcore(char*
area.
> >
> > Looks like nobody has realized this problem in the past because
> those
> > registers are not too important for debugging kernel problems...
> >
> > This patch fixes this problem and now control and floating point
> registers
> > are printed corre
important for debugging kernel problems...
This patch fixes this problem and now control and floating point registers
are printed correctly.
Signed-off-by: Michael Holzheu
---
s390.c | 16
s390x.c | 32
2 files changed, 24 insertions(+), 24
Hello Dave,
On Mon, 2011-08-15 at 13:28 -0400, Dave Anderson wrote:
> OK -- I had checked it out only a live system, but that code
> path wouldn't be exercised in that case, so I'll add in the
> symbol_exists() check to s390x_back_trace_cmd().
Thanks!
> Also, the "if (!stack_addr)" check in get
Hi Dave,
Sorry, the restart stack patch is missing a check if the restart_stack
symbols exists. Without this check, we get error messages for older
kernels. Here the updated patch.
Sorry for the noise.
Signed-off-by: Michael Holzheu
---
s390x.c | 17 ++---
1 file changed, 14
00011e5200
011e5238 005c6a00 00106026 00907e68
#0 [00907eb0] cpu_idle at 106026
#1 [00907ef8] start_kernel at 9799e
Signed-off-by: Michael Holzheu
---
s390x.c | 71 ++--
1 file changed, 60 insertions(+), 11
Hi Dave,
With Linux 3.0.1 on s390 we have a new kernel stack for the PSW restart
interrupt. See kernel git commit 7dd6b3343fdc190712d1620ee8848d25c4c77c33
for details. With this patch the crash "bt" command will find this stack.
Signed-off-by: Michael Holzheu
---
s390
Hello Dave,
On Wed, 2011-05-04 at 10:13 -0400, Dave Anderson wrote:
> > > I'm not particularly enamored with the use of the zero-filled
> > > "double-number" frame fields -- mainly because it's different
> > > than all of the other architectures (even the s390).
> > > The other arches just move th
Hello Dave,
On Wed, 2011-05-04 at 09:56 -0400, Dave Anderson wrote:
> Hi Michael,
>
> A couple minor points about this patch...
>
> I moved the two new offset_table entries to the end of
> the structure. Since the offset_table is exported to extension
> modules, changing members in the middle o
Hi Dave,
If we get a program check interrupt while we are on the task stack, crash
only shows the stack trace up to the program check interrupt.
Example:
#0 [3d2bb6e0] raw3215_make_room at 3e2c90
#1 [3d2bb730] con3215_notify at 3e3a26
#2 [3d2bb760] notifier_call_chain at 4c31d0
#3 [3d2bb7b8]
Hi Dave,
I got an s390x dump of a Linux 2.6.36 system, where a task (kmcheck, pid=44) is
missing in the ps output. I debugged the problem and I think that I found the
reason:
It looks like that crash does not walk the linked list of the pid hash table
to the end, if it finds a NULL pointer in the
directory tree is created as it can be seen on a live system under
"/sys/kernel/debug/s390dbf".
Michael
Signed-off-by: Michael Holzheu
---
s390dbf.c | 126 +++---
1 file changed, 113 insertions(+), 13 deletions(-)
--- a/s390d
Hello Dave,
Dave Anderson wrote on 11/16/2010 20:30:48:
> > Please review the changes and send in your comments.
>
> Hello Mahesh,
>
> The patch-set looks good so far, except for one minor nit.
>
> Why is "S390" accepted as legitimate here in read_dump_header()?
>
> @@ -349,6 +352,10 @@ restart
Hello Dave,
Currently the s390dbf command uses KL_UINT() for reading pointers. This
works only if the pointers are below 4 GiB. To fix this issue I now use
a new KL_ULONG() function for reading pointers correctly.
Michael
---
s390dbf.c | 13 +++--
1 file changed, 7 insertions(+), 6 del
On Fri, 2010-08-27 at 09:48 -0400, Dave Anderson wrote:
> - "Michael Holzheu" wrote:
> > I think, when reading the array, we should use the array size as
> > loop exit criteria instead of checking for NULL termination.
>
> Agreed -- I'll just change your
Hi Dave,
Crash seems to assume that the "task_state_array" is NULL terminated. This is
not the case:
static const char *task_state_array[] = {
"R (running)", /* 0 */
"S (sleeping)", /* 1 */
...
"X (dead)" /* 32 */
};
I have a dump where thi
On Mon, 2010-06-21 at 18:45 +0200, Michael Holzheu wrote:
> On Mon, 2010-06-21 at 18:31 +0200, Bernhard Walle wrote:
> > * Michael Holzheu [2010-06-21 18:24]:
> > > http://people.redhat.com/anderson/crash-5.0.4.tar.gz
> >
> > 5.0.5 has been released.
>
> A
On Mon, 2010-06-21 at 18:31 +0200, Bernhard Walle wrote:
> * Michael Holzheu [2010-06-21 18:24]:
> > http://people.redhat.com/anderson/crash-5.0.4.tar.gz
>
> 5.0.5 has been released.
Ah ok, then the link on the main page must be updated:
http://people.redhat.com/anderson/
Mi
Hi Dave,
Currently for the s390dbf command we use stdout as file descriptor. This
has the drawback that it is not possible to grep through the output of
the command.
To solve the problem with this patch we use "fp" instead of "stdout".
Michael
PS: I am no longer able to download the crash tarba
Hi Dave,
On Mon, 2010-04-26 at 11:56 -0400, Dave Anderson wrote:
> Sorry -- I take it back. Running a test shows that it breaks "bt -a"
> on Xen dumpfiles where the cpus are marked offline prior to dumping
> the kernel memory.
>
> I think this should be moved to the processor-specific backtrace
> > Good idea! The following attached patch also works for me.
> >
> > Michael
>
> That looks good -- queued for the next release.
Thanks!
Michael
--
Crash-utility mailing list
Crash-utility@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility
Hello Dave,
On Mon, 2010-04-26 at 10:29 -0400, Dave Anderson wrote:
> I'd prefer not to leave them out of the various internal task arrays,
> especially the active_set[] array. Regardless of their on/offline
> status, they do still exist as tasks, have runqueues, etc.
Ok, fine.
> If you're just
Hello Dave,
Currently for "bt -a" also swapper tasks on offline CPUs are printed
(at least on s390). Wouldn't it be better to only print a backtrace,
when the task is running on an online CPU?
My suggestion would be to implement that with the following patch
by only setting the panic threads for
Hallo Luc,
On Mon, 2010-03-01 at 13:48 -0500, Chouinard, Luc wrote:
> Hi Michael -
> How did a fundamental bool type (which, if I'm not mistacking, is a c++
> type) got into a kernel object?
I assume that this comes from the C99 datatype "_Bool". This is used in
the kernel to define "bool":
type
Hi Luc,
I have a sial script that uses structures that contain members of type
"bool". When I run the script I get:
File ../devices.sial, line 279, Error: Oops drilldowntype
I looked into the sial code and found that the drilldowntype() functions
fails because no "case TYPE_CODE_BOOL" is defined
Hi Dave,
On Fri, 2010-02-26 at 10:42 -0500, Dave Anderson wrote:
> > I tested vanilla 2.6.32, RHEL5, SLES10 and SLES11.
> >
> > But I found a bug with RHEL4:
>
> OK good -- I'm glad I asked. I note that RHEL3 doesn't even have
> a "panic_stack" member. That being the case, this won't work as
>
Hi Dave,
On Fri, 2010-02-26 at 09:50 -0500, Dave Anderson wrote:
> - "Michael Holzheu" wrote:
>
> > Hi Dave,
> >
> > This patch fixes several bugs in the s390 stack backtrace code
> > * Add panic stack as second interrupt stack
> > * Fix prin
Hi Dave,
This patch fixes several bugs in the s390 stack backtrace code
* Add panic stack as second interrupt stack
* Fix printing of access registers (4 bytes instead of 8 bytes)
* Use u64 for s390x register 14
* Fix interrupt stack handling for s390x (use 160 byte overhead instead of 96)
---
s3
Hallo Dave,
On Thu, 2010-02-18 at 13:52 -0500, Dave Anderson wrote:
> - Preparation for future s390x ELF dumpfile format.
>(holz...@linux.vnet.ibm.com)
I did a short test for the s390x ELF support. Everything worked
as expected.
Thanks!
Michael
--
Crash-utility mailing list
Crash-utility@
On Tue, 2010-02-16 at 11:34 +0100, Michael Holzheu wrote:
> Dave,
>
> On Mon, 2010-02-15 at 16:56 -0500, Dave Anderson wrote:
> > - "Michael Holzheu" wrote:
> > > Sorry, I did not read your note carefully. If you want to do that then
> > > my curr
Dave,
On Mon, 2010-02-15 at 16:56 -0500, Dave Anderson wrote:
> - "Michael Holzheu" wrote:
> > Sorry, I did not read your note carefully. If you want to do that then
> > my current implementation is wrong. The problem is that now I expect ELF
> > note structure
On Mon, 2010-02-15 at 17:06 +0100, Michael Holzheu wrote:
> > No major changes other than to rename the machdep->elf_note_add() function
> > to machdep->dumpfile_init(). The idea is that, in the future, if there is
> > ever *anything* in *any* type of dumpfile header th
Dave,
I will check the new functionality after you released your next crash
package.
Thanks!
Michael
On Fri, 2010-02-12 at 15:02 -0500, Dave Anderson wrote:
> OK, the patch as queued is attached.
>
> No major changes other than to rename the machdep->elf_note_add() function
> to machdep->dumpf
Hi Dave,
On Fri, 2010-02-12 at 10:41 -0500, Dave Anderson wrote:
> - "Dave Anderson" wrote:
>
> > If you're happy with the changes above, I can do it here, make sure
> > it compiles, and queue it for the next release.
>
> Here's my proposed patch, along with cleanups for these compiler warn
On Fri, 2010-02-12 at 09:53 -0500, Dave Anderson wrote:
> > A new machdep member function "elf_note_add()" is added. In this function
> > we setup the s390x CPU information.
>
> OK, this looks good -- these are the changes I would make.
>
> Since a new entry-point is being made in the machdep_tab
Hi Dave,
Next try... I think this one is better:
I added a new machdep function "elf_note_add()" and moved almost all
into s390x.c:
Add ELF core dump support for s390x
This patch enables crash for reading s390x (64 bit) ELF core dumps. The
following new ELF note sections are added by this patch
Hello Dave,
On Thu, 2010-02-11 at 11:13 -0500, Dave Anderson wrote:
> OK, first the simple stuff...
>
> The change to is_shared_object() doesn't make sense to me.
> That function is only used when loading extension modules.
> You make the following change in the ELFCLASS32 section.
> So if a 32-b
1 - 100 of 154 matches
Mail list logo
