Reasons why kdump isn't activated
by Gallus
Hi,
what can be any reasons why kdump mechanism isn't triggered? My first
though is that it means a hardware failure, not a kernel problem.
Regards,
Mariusz Gniazdowski
14 years, 10 months
Re: [Crash-utility] Running idle threads show wrong CPU numbers
by Dave Anderson
----- "Michael Holzheu" <holzheu(a)linux.vnet.ibm.com> wrote:
> Hi again,
> > When I change get_smp_cpus() to return "get_highest_cpu_online() + 1" I
> > see five swapper idle tasks when using "ps". The problem I now have is
> > that I have to provide a backtrace for the offline cpus. But the offline
> > CPUs do not have any stack on s390. Is there a way to tell crash that
> > there is no backtrace available? Probably I overlooked something...
>
> Ok, I think I got it now. In case of an offline CPU, I will use
> "task_struct_thread_ksp" like I do it for non active tasks.
>
> When I do that I get for the swapper tasks with the offline CPUs:
>
> PID: 0 TASK: 18d38340 CPU: 2 COMMAND: "swapper"
> #0 [18d3feb8] ret_from_fork at 117e12
>
> PID: 0 TASK: 18d40440 CPU: 3 COMMAND: "swapper"
> #0 [18d47eb8] ret_from_fork at 117e12
I'm not why you should do anything. The cpu is offline and for all
practical purposes it doesn't exist, so why bother?
The patch I have queued just uses get_highest_cpu_online()+1 and
does nothing else. But I only tested it on a live system, and
any backtrace attempt on the offlined swapper task just shows
(active). What happens when you do a "bt -a" with a dumpfile?
Dave
14 years, 10 months
Re: [Crash-utility] Running idle threads show wrong CPU numbers
by Dave Anderson
----- "Michael Holzheu" <holzheu(a)linux.vnet.ibm.com> wrote:
> Hi Dave,
>
> I have a problem with a dump where I have defined five CPUs and two of
> them are offline. In fact the logical CPUs are defined as follows:
>
> 0 on
> 1 on
> 2 off
> 3 off
> 4 on
>
> The CPU online map looks correct:
>
> crash> print/x *cpu_online_mask
> $4 = {
> bits = {0x13} ---> b10011
> }
>
> When I issue "ps" I see that all running tasks are idle, but the CPU
> numbers are not correct (0,1,2 and not 0,1,4):
>
> PID PPID CPU TASK ST %MEM VSZ RSS COMM
> > 0 0 0 800ef0 RU 0.0 0 0 [swapper]
> > 0 0 1 18c24240 RU 0.0 0 0 [swapper]
> > 0 0 2 18c2c340 RU 0.0 0 0 [swapper]
>
> I tried to debug the problem, but got stuck somewhere in "task.c". I
> think there is a problem with the idle threads initialization, where the
> online map is not considered.
>
> Maybe you can see the bug immediately. Otherwise I will have spend more
> effort for debugging that problem. I hope not :-)
Does "sys" show 5 or 3 cpus? I'm guessing it shows 3, but should show 5.
It looks like the s390/s390x files need to use "get_highest_cpu_online()-1"
(like x86_64 and ppc64) in order to determine the number of cpus to account
for. As it is now, they do this, and would therefore only account for the
first 3 cpus:
int
s390x_get_smp_cpus(void)
{
return get_cpus_online();
}
int
s390_get_smp_cpus(void)
{
return get_cpus_online();
}
Dave
14 years, 10 months
Re: [Crash-utility] [PATCH] s390: Member names changed in struct _lowcore
by Dave Anderson
----- "Michael Holzheu" <holzheu(a)linux.vnet.ibm.com> wrote:
> Hi,
>
> For s390 the "st_status_fixed_logout" member of "struct _lowcore" will be
> changed to "psw_save_area" in 2.6.33. This patch will ensure that the correct
> member will be used depending on the kernel version.
>
> Best Regards
>
> Michael
Looks good to me. I couldn't get a clean non-html-cluttered patch file
from your patch-inlined post from my mailer, so can you verify that the
attached hand-made patch works for you?
Thanks,
Dave
14 years, 10 months
Re: [Crash-utility] Reasons why kdump isn't activated
by Dave Anderson
----- "Laurence A. Oberman" <online(a)photonlinux.com> wrote:
> Hi Dave
>
> I use crash all the time on SLES dumps. I still have problems with the
> SLAB stuff, even with 5.0.
>
> "crash: unable to initialize kmem slab cache subsystem"
>
> Is there a fix for this or am I missing something in creating the
> debug vmlinux kernel
>
> crash 5.0.0
> Copyright (C) 2002-2010 Red Hat, Inc.
> Copyright (C) 2004, 2005, 2006 IBM Corporation
> Copyright (C) 1999-2006 Hewlett-Packard Co
> Copyright (C) 2005, 2006 Fujitsu Limited
> Copyright (C) 2006, 2007 VA Linux Systems Japan K.K.
> Copyright (C) 2005 NEC Corporation
> Copyright (C) 1999, 2002, 2007 Silicon Graphics, Inc.
> Copyright (C) 1999, 2000, 2001, 2002 Mission Critical Linux, Inc.
> This program is free software, covered by the GNU General Public License,
> and you are welcome to change it and/or distribute copies of it under
> certain conditions. Enter "help copying" to see the conditions.
> This program has absolutely no warranty. Enter "help warranty" for
> details.
>
> GNU gdb (GDB) 7.0
> Copyright (C) 2009 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law. Type "show copying"
> and "show warranty" for details.
> This GDB was configured as "x86_64-unknown-linux-gnu"...
>
> WARNING: could not find MAGIC_START!
> please wait... (gathering kmem slab cache data)\
> crash: seek error: kernel virtual address: 1082fffea00 type: "kmem_cache buffer" ---->
>
> crash: unable to initialize kmem slab cache subsystem
>
> SYSTEM MAP: map.0
> DEBUG KERNEL: vmlinux (2.6.5-7.244-smp)
> DUMPFILE: dump.0
> CPUS: 4
> DATE: Sat Feb 6 12:43:37 2010
> UPTIME: 213503982289 days, 20:38:24
> LOAD AVERAGE: 260.75, 259.77, 258.95
> TASKS: 1167
> NODENAME: linuscs73
> RELEASE: 2.6.5-7.252-smp
> VERSION: #2 SMP Mon Jun 22 13:11:57 PDT 2009
> MACHINE: x86_64 (2666 Mhz)
> MEMORY: 32.7 GB
> PANIC: "manual"
> PID: 8741
> COMMAND: "lkcd_config"
> TASK: 107ed5d6b40 [THREAD_INFO: 1024f3ac000]
> CPU: 2
> STATE: TASK_RUNNING (PANIC)
>
>
> Thanks
> Laurence
The "seek error" indicates that the kmem slab page associated with
virtual address 1082fffea00, which is unity-mapped to physical
address 82fffea00, could not be found in the dump.0 file.
If we presume that it is a "correct" address, physical address
82fffea00 is *very* close to the end of physical memory on that
system, which shows "32.7 GB". If you enter:
crash> kmem -p | tail
and wait a while because of the size of the dump, it will eventually
dump the end of the system's mem_map array of physical pages, where
the second column in the list contains the physical address.
I only have one SLES9 (2.6.5-7.315-smp) dumpfile example, which is
a 16GB dumpfile, and the output looks like this:
crash> kmem -p | tail
10407efdd98 407ff5000 0 0 0 d000080
10407efddd0 407ff6000 0 0 0 d000080
10407efde08 407ff7000 0 0 0 d000080
10407efde40 407ff8000 0 0 0 d000080
10407efde78 407ff9000 0 0 0 d000080
10407efdeb0 407ffa000 0 0 0 d000080
10407efdee8 407ffb000 0 0 0 d000080
10407efdf20 407ffc000 0 0 0 d000080
10407efdf58 407ffd000 0 0 0 d000080
10407efdf90 407ffe000 0 0 0 d000080
crash>
where 407ffe000 is the last page of physical memory on the system.
If you do the same thing, how does the last physical page compare
to 82fffea00?
Dave
output looks like this
14 years, 10 months
Re: [Crash-utility] Reasons why kdump isn't activated
by Laurence A. Oberman
Hi Dave
I use crash all the time on SLES dumps. I still have problems with the SLAB stuff, even with 5.0.
"crash: unable to initialize kmem slab cache subsystem"
Is there a fix for this or am I missing something in creating the debug vmlinux kernel
crash 5.0.0
Copyright (C) 2002-2010 Red Hat, Inc.
Copyright (C) 2004, 2005, 2006 IBM Corporation
Copyright (C) 1999-2006 Hewlett-Packard Co
Copyright (C) 2005, 2006 Fujitsu Limited
Copyright (C) 2006, 2007 VA Linux Systems Japan K.K.
Copyright (C) 2005 NEC Corporation
Copyright (C) 1999, 2002, 2007 Silicon Graphics, Inc.
Copyright (C) 1999, 2000, 2001, 2002 Mission Critical Linux, Inc.
This program is free software, covered by the GNU General Public License,
and you are welcome to change it and/or distribute copies of it under
certain conditions. Enter "help copying" to see the conditions.
This program has absolutely no warranty. Enter "help warranty" for details.
GNU gdb (GDB) 7.0
Copyright (C) 2009 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-unknown-linux-gnu"...
WARNING: could not find MAGIC_START!
please wait... (gathering kmem slab cache data)\
crash: seek error: kernel virtual address: 1082fffea00 type: "kmem_cache buffer" ---->
crash: unable to initialize kmem slab cache subsystem
SYSTEM MAP: map.0
DEBUG KERNEL: vmlinux (2.6.5-7.244-smp)
DUMPFILE: dump.0
CPUS: 4
DATE: Sat Feb 6 12:43:37 2010
UPTIME: 213503982289 days, 20:38:24
LOAD AVERAGE: 260.75, 259.77, 258.95
TASKS: 1167
NODENAME: linuscs73
RELEASE: 2.6.5-7.252-smp
VERSION: #2 SMP Mon Jun 22 13:11:57 PDT 2009
MACHINE: x86_64 (2666 Mhz)
MEMORY: 32.7 GB
PANIC: "manual"
PID: 8741
COMMAND: "lkcd_config"
TASK: 107ed5d6b40 [THREAD_INFO: 1024f3ac000]
CPU: 2
STATE: TASK_RUNNING (PANIC)
Thanks
Laurence
----- Original Message -----
From: "Chandan12 K" <chandan12.k(a)tcs.com>
To: "Discussion list for crash utility usage, maintenance and development" <crash-utility(a)redhat.com>
Cc: "Discussion list for crash utility usage, maintenance and development" <crash-utility(a)redhat.com>, crash-utility-bounces(a)redhat.com
Sent: Tuesday, February 9, 2010 8:59:01 AM
Subject: Re: [Crash-utility] Reasons why kdump isn't activated
First you need to figure out the reason of your system failure. If its complete power failure, then kexec wont be able to load a new kernel in current context.
Secondly, is kexec properly configured in your system?
Chandan Kumar
Tata Consultancy Services
Mailto: chandan12.k(a)tcs.com
Website: http://www.tcs.com
____________________________________________
Experience certainty. IT Services
Business Solutions
Outsourcing
____________________________________________
From: Gallus <gall.cwpl(a)gmail.com>
To: "Discussion list for crash utility usage, maintenance and development" <crash-utility(a)redhat.com>
Date: 02/09/2010 07:10 PM
Subject: [Crash-utility] Reasons why kdump isn't activated
Sent by: crash-utility-bounces(a)redhat.com
Hi,
what can be any reasons why kdump mechanism isn't triggered? My first
though is that it means a hardware failure, not a kernel problem.
Regards,
Mariusz Gniazdowski
--
Crash-utility mailing list
Crash-utility(a)redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility
=====-----=====-----=====
Notice: The information contained in this e-mail
message and/or attachments to it may contain
confidential or privileged information. If you are
not the intended recipient, any dissemination, use,
review, distribution, printing or copying of the
information contained in this e-mail message
and/or attachments to it are strictly prohibited. If
you have received this communication in error,
please notify us by reply e-mail or telephone and
immediately and permanently delete the message
and any attachments. Thank you
--
Crash-utility mailing list
Crash-utility(a)redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility
14 years, 10 months
Re: [Crash-utility] crash segfaults on a dump if a module was coming up
by Dave Anderson
----- "John Wright" <john.wright(a)hp.com> wrote:
> Hello,
>
> I have a dump that causes crash to segfault:
>
> $ crash kernel_link dump.201002031023
>
> crash 5.0.0
> Copyright (C) 2002-2010 Red Hat, Inc.
> Copyright (C) 2004, 2005, 2006 IBM Corporation
> Copyright (C) 1999-2006 Hewlett-Packard Co
> Copyright (C) 2005, 2006 Fujitsu Limited
> Copyright (C) 2006, 2007 VA Linux Systems Japan K.K.
> Copyright (C) 2005 NEC Corporation
> Copyright (C) 1999, 2002, 2007 Silicon Graphics, Inc.
> Copyright (C) 1999, 2000, 2001, 2002 Mission Critical Linux, Inc.
> This program is free software, covered by the GNU General Public License,
> and you are welcome to change it and/or distribute copies of it under
> certain conditions. Enter "help copying" to see the conditions.
> This program has absolutely no warranty. Enter "help warranty" for details.
>
> GNU gdb (GDB) 7.0
> Copyright (C) 2009 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law. Type "show copying"
> and "show warranty" for details.
> This GDB was configured as "x86_64-unknown-linux-gnu"...
>
> please wait... (gathering module symbol data)Segmentation fault
> (core dumped)
>
> Interestingly, it doesn't crash every time. But I tracked it down to a
> change in Linux 2.6.32 (see [1]) which changes how the module symbol
> table is stored. It only seems to make a difference when a module is
> still coming up.
>
> Here's what's happening, as I understand it:
>
> - crash loads the contents of a struct module from memory into a buffer
> (pointed to by a char * called modbuf)
> - It gets some of the fields out of it and stores it in an internal
> struct load_module lm. Of importance here:
> - mod_base : the kernel address of the core of the module,
> corresponding to the module_core member of struct module
> - mod_size : the core_size element of the struct module
> - It allocates a buffer of size mod_size, called module_buf, and reads
> mod_size bytes from the kernel address mod_base (from the dumpfile)
> into module_buf
> - Then, it gets the kernel address for the symbol table from modbuf,
> given by the symtab member of struct module, storing it in a variable
> called ksymtab
> - Then, it tries to get the local address of the symbol table via
>
> locsymtab = module_buf + (ksymtab - lm->mod_base);
>
> In other words, it's getting the offset between mod->symtab and
> mod->module_core, so that it can treat module_buf as if it were
> module_core.
>
> But that calculation only works if the symbol table is actually in the
> module core. As it turns out, in Linux 2.6.32, the symbol table
> handling works a little differently: mod->symtab points to somewhere
> inside mod->module_init until after its init function finishes running.
> After that, it gets set to the value of mod->symtab_core.
>
> Anyway, since the module's init section wasn't loaded into module_buf,
> this won't work for modules that are in the process of loading. It
> would be fairly simple to stop it from crashing by making sure locsymtab
> doesn't point outside the area allocated for module_buf (patch
> attached). Actually making sure it loads the symbol table would be a
> little more tricky, involving loading the init section as well, but
> maybe that's not necessary (hopefully someone debugging a module that
> crashes in its init function would be able to load debugging symbols for
> the module after crash loads).
>
> I've attached a simple module that panics the kernel in its init
> function, and a patch to crash that just ignores the ksymtab and kstrtab
> information if they point outside of the module core.
>
> [1]:
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit...
>
> --
> +-----------------------------------------+
> | John Wright <john.wright(a)hp.com> |
> | Hewlett-Packard Telco Platform Software |
> +-----------------------------------------+
Nice -- makes perfect sense. Somewhat similar to a 4.0-7.1 change where
a module was kmalloc'ing its own exported symbol list outside of its own
virtual address space, and then overwriting its own symbol list pointer.
And again, thanks for doing the heavy lifting. Queued for the next release.
Dave
14 years, 10 months
Re: [Crash-utility] [patch]Crash can't process xen dump core files larger that 4GB.
by Dave Anderson
----- "Dave Anderson" <anderson(a)redhat.com> wrote:
>
> What could be done is to have the xc_core_verify() initialization code read
> the dumpfile header into an "original" xc_core_header structure type, verify it
> as one of the "old-style" dumpfiles, but then store the offsets into your
> updated xc_core_header structure.
>
> Dave
How does the attached patch work for you?
Dave
14 years, 10 months
crash segfaults on a dump if a module was coming up
by John Wright
Hello,
I have a dump that causes crash to segfault:
$ crash kernel_link dump.201002031023
crash 5.0.0
Copyright (C) 2002-2010 Red Hat, Inc.
Copyright (C) 2004, 2005, 2006 IBM Corporation
Copyright (C) 1999-2006 Hewlett-Packard Co
Copyright (C) 2005, 2006 Fujitsu Limited
Copyright (C) 2006, 2007 VA Linux Systems Japan K.K.
Copyright (C) 2005 NEC Corporation
Copyright (C) 1999, 2002, 2007 Silicon Graphics, Inc.
Copyright (C) 1999, 2000, 2001, 2002 Mission Critical Linux, Inc.
This program is free software, covered by the GNU General Public License,
and you are welcome to change it and/or distribute copies of it under
certain conditions. Enter "help copying" to see the conditions.
This program has absolutely no warranty. Enter "help warranty" for details.
GNU gdb (GDB) 7.0
Copyright (C) 2009 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-unknown-linux-gnu"...
please wait... (gathering module symbol data)Segmentation fault (core dumped)
Interestingly, it doesn't crash every time. But I tracked it down to a
change in Linux 2.6.32 (see [1]) which changes how the module symbol
table is stored. It only seems to make a difference when a module is
still coming up.
Here's what's happening, as I understand it:
- crash loads the contents of a struct module from memory into a buffer
(pointed to by a char * called modbuf)
- It gets some of the fields out of it and stores it in an internal
struct load_module lm. Of importance here:
- mod_base : the kernel address of the core of the module,
corresponding to the module_core member of struct module
- mod_size : the core_size element of the struct module
- It allocates a buffer of size mod_size, called module_buf, and reads
mod_size bytes from the kernel address mod_base (from the dumpfile)
into module_buf
- Then, it gets the kernel address for the symbol table from modbuf,
given by the symtab member of struct module, storing it in a variable
called ksymtab
- Then, it tries to get the local address of the symbol table via
locsymtab = module_buf + (ksymtab - lm->mod_base);
In other words, it's getting the offset between mod->symtab and
mod->module_core, so that it can treat module_buf as if it were
module_core.
But that calculation only works if the symbol table is actually in the
module core. As it turns out, in Linux 2.6.32, the symbol table
handling works a little differently: mod->symtab points to somewhere
inside mod->module_init until after its init function finishes running.
After that, it gets set to the value of mod->symtab_core.
Anyway, since the module's init section wasn't loaded into module_buf,
this won't work for modules that are in the process of loading. It
would be fairly simple to stop it from crashing by making sure locsymtab
doesn't point outside the area allocated for module_buf (patch
attached). Actually making sure it loads the symbol table would be a
little more tricky, involving loading the init section as well, but
maybe that's not necessary (hopefully someone debugging a module that
crashes in its init function would be able to load debugging symbols for
the module after crash loads).
I've attached a simple module that panics the kernel in its init
function, and a patch to crash that just ignores the ksymtab and kstrtab
information if they point outside of the module core.
[1]: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit...
--
+-----------------------------------------+
| John Wright <john.wright(a)hp.com> |
| Hewlett-Packard Telco Platform Software |
+-----------------------------------------+
14 years, 10 months
[PATCH] s390: Member names changed in struct _lowcore
by Michael Holzheu
Hi,
For s390 the "st_status_fixed_logout" member of "struct _lowcore" will be
changed to "psw_save_area" in 2.6.33. This patch will ensure that the correct
member will be used depending on the kernel version.
Best Regards
Michael
---
defs.h | 1 +
s390.c | 24 ++++++++++++++++++------
s390x.c | 23 ++++++++++++++++++-----
3 files changed, 37 insertions(+), 11 deletions(-)
--- a/defs.h
+++ b/defs.h
@@ -1494,6 +1494,7 @@ struct offset_table {
long attribute_owner;
long module_sect_attr_attr;
long module_sections_attrs;
+ long s390_lowcore_psw_save_area;
};
struct size_table { /* stash of commonly-used sizes */
--- a/s390.c
+++ b/s390.c
@@ -69,6 +69,19 @@ static int s390_is_uvaddr(ulong, struct
/*
+ * Initialize member offsets
+ */
+static void s390_offsets_init(void)
+{
+ if (MEMBER_EXISTS("_lowcore", "st_status_fixed_logout"))
+ MEMBER_OFFSET_INIT(s390_lowcore_psw_save_area, "_lowcore",
+ "st_status_fixed_logout");
+ else
+ MEMBER_OFFSET_INIT(s390_lowcore_psw_save_area, "_lowcore",
+ "psw_save_area");
+}
+
+/*
* Do all necessary machine-specific setup here. This is called several
* times during initialization.
*/
@@ -132,6 +145,7 @@ s390_init(int when)
machdep->hz = HZ;
machdep->section_size_bits = _SECTION_SIZE_BITS;
machdep->max_physmem_bits = _MAX_PHYSMEM_BITS;
+ s390_offsets_init();
break;
case POST_INIT:
@@ -632,8 +646,7 @@ s390_back_trace_cmd(struct bt_info *bt)
return;
}
s390_get_lowcore(cpu,lowcore);
- psw_flags = ULONG(lowcore + MEMBER_OFFSET("_lowcore",
- "st_status_fixed_logout"));
+ psw_flags = ULONG(lowcore + OFFSET(s390_lowcore_psw_save_area));
if(psw_flags & 0x10000UL){
fprintf(fp,"Task runs in userspace\n");
s390_print_lowcore(lowcore,bt,0);
@@ -755,7 +768,7 @@ s390_print_lowcore(char* lc, struct bt_i
char* ptr;
unsigned long tmp[4];
- ptr = lc + MEMBER_OFFSET("_lowcore","st_status_fixed_logout");
+ ptr = lc + OFFSET(s390_lowcore_psw_save_area);
tmp[0]=ULONG(ptr);
tmp[1]=ULONG(ptr + S390_WORD_SIZE);
@@ -915,9 +928,8 @@ s390_get_stack_frame(struct bt_info *bt,
return;
if(s390_has_cpu(bt->task) && esp){
- *eip = ULONG(lowcore + MEMBER_OFFSET("_lowcore",
- "st_status_fixed_logout") + S390_WORD_SIZE)
- & S390_ADDR_MASK;
+ *eip = ULONG(lowcore + OFFSET(s390_lowcore_psw_save_area) +
+ S390_WORD_SIZE) & S390_ADDR_MASK;
} else {
if(!STRUCT_EXISTS("stack_frame")){
r14_offset = 56;
--- a/s390x.c
+++ b/s390x.c
@@ -65,6 +65,18 @@ static void s390x_dump_line_number(ulong
static struct line_number_hook s390x_line_number_hooks[];
static int s390x_is_uvaddr(ulong, struct task_context *);
+/*
+ * Initialize member offsets
+ */
+static void s390x_offsets_init(void)
+{
+ if (MEMBER_EXISTS("_lowcore", "st_status_fixed_logout"))
+ MEMBER_OFFSET_INIT(s390_lowcore_psw_save_area, "_lowcore",
+ "st_status_fixed_logout");
+ else
+ MEMBER_OFFSET_INIT(s390_lowcore_psw_save_area, "_lowcore",
+ "psw_save_area");
+}
/*
* Do all necessary machine-specific setup here. This is called several
@@ -130,6 +142,7 @@ s390x_init(int when)
machdep->hz = HZ;
machdep->section_size_bits = _SECTION_SIZE_BITS;
machdep->max_physmem_bits = _MAX_PHYSMEM_BITS;
+ s390x_offsets_init();
break;
case POST_INIT:
@@ -642,8 +655,8 @@ s390x_back_trace_cmd(struct bt_info *bt)
return;
}
s390x_get_lowcore(cpu,lowcore);
- psw_flags = ULONG(lowcore + MEMBER_OFFSET("_lowcore",
- "st_status_fixed_logout"));
+ psw_flags = ULONG(lowcore + OFFSET(s390_lowcore_psw_save_area));
+
if(psw_flags & 0x1000000000000ULL){
fprintf(fp,"Task runs in userspace\n");
s390x_print_lowcore(lowcore,bt,0);
@@ -766,7 +779,7 @@ s390x_print_lowcore(char* lc, struct bt_
char* ptr;
unsigned long tmp[4];
- ptr = lc + MEMBER_OFFSET("_lowcore","st_status_fixed_logout");
+ ptr = lc + OFFSET(s390_lowcore_psw_save_area);
tmp[0]=ULONG(ptr);
tmp[1]=ULONG(ptr + S390X_WORD_SIZE);
@@ -945,8 +958,8 @@ s390x_get_stack_frame(struct bt_info *bt
return;
if(s390x_has_cpu(bt->task) && esp){
- *eip = ULONG(lowcore + MEMBER_OFFSET("_lowcore",
- "st_status_fixed_logout") + S390X_WORD_SIZE);
+ *eip = ULONG(lowcore + OFFSET(s390_lowcore_psw_save_area) +
+ S390X_WORD_SIZE);
} else {
if(!STRUCT_EXISTS("stack_frame")){
r14_offset = 112;
14 years, 10 months
