[PATCH] Fix build on non-Xen architectures
by Bernhard Walle
This patch fixes the following build error on s390/s390x and ppc64.
gcc -O2 -fmessage-length=0 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector \
-g -fno-builtin-memset -fno-strict-aliasing -fno-builtin-memset \
-o `cat mergeobj` libgdb.a ../bfd/libbfd.a ../readline/libreadline.a \
../opcodes/libopcodes.a ../libiberty/libiberty.a \
-lm -lncurses ../libiberty/libiberty.a -ldl -rdynamic `cat mergelibs`
../../crashlib.a(kernel.o): In function `back_trace':
/usr/src/packages/BUILD/crash-4.0-7.3/kernel.c:2095: undefined reference to
Signed-off-by: Bernhard Walle <bwalle(a)suse.de>
---
kernel.c | 5 +++++
1 file changed, 5 insertions(+)
--- a/kernel.c
+++ b/kernel.c
@@ -2091,10 +2091,15 @@ complete_trace:
goto complete_trace;
if (BT_REFERENCE_FOUND(bt)) {
+#ifdef XEN_HYPERVISOR_ARCH
if (XEN_HYPER_MODE())
xen_hyper_print_bt_header(fp, bt->task, 0);
else
print_task_header(fp, task_to_context(bt->task), 0);
+#else
+ print_task_header(fp, task_to_context(bt->task), 0);
+#endif /* XEN_HYPERVISOR_ARCH */
+
BCOPY(&btsave, bt, sizeof(struct bt_info));
bt->ref = NULL;
machdep->back_trace(bt);
15 years, 9 months
Re: [Crash-utility] "cannot access vmalloc'd module memory" when loading kdump'ed vmcore in crash
by Dave Anderson
----- "Kevin Worth" <kevin.worth(a)hp.com> wrote:
> Dave,
>
> I do indeed have a /dev/kmem on my live system. One other thing... is
> the physical limit of 0xb8000000 imposed because of the amount of
> memory on my system or because it is the maximum addressable memory
> without using PAE? My kernel does have PAE enabled (CONFIG_HIGHMEM_32G
> or whatever the option is), though not sure if that makes a
> difference, just checking. Things work just fine on an identical
> system that has 2GB of memory instead of 4GB. :\
The physical limit is imposed by how much physical memory
can be unity-mapped by the architecture's virtual address
space, or more simply put how many bits of kernel virtual
address space are available, coupled with how you split
your virtual memory between user space and kernel space.
On 32-bit systems with kernel virtual space starting at
c0000000, there is only 1GB of virtual memory between
c0000000 and ffffffff+1. Also the system needs to
reserve some of that 1GB (128MB to be exact) for vmalloc
space. So that leaves 896MB of directly-mappable
(unity-mapped) kernel virtual space, so "high_memory"
is set to (c0000000 + 896MB) or f8000000.
On your system, kernel virtual memory starts at 40000000,
so there's 3GB of kernel virtual space. It still needs
the 128MB of vmalloc space, so your high_memory limit
is still f8000000, but there's a much larger directly-mappable
range between 40000000 and f8000000.
It has nothing to do with PAE. And the reason things work
"fine" on your 2GB system is because /dev/mem can always
access 2GB because its unity-mapped equivalent is less
than high_memory. It's only going to be a problem when
your system has more than 3GB of physical memory. (3GB-128MB)
to be exact...
Dave
15 years, 9 months
Re: [Crash-utility] "cannot access vmalloc'd module memory" when loading kdump'ed vmcore in crash
by Dave Anderson
----- "Kevin Worth" <kevin.worth(a)hp.com> wrote:
> Dave,
>
> That does seem pretty strange that the physical address is coming out
> beyond the 4GB mark and that the read actually succeeds. Just checked
> on the Ubuntu patches to the 2.6.20 kernel (
> http://archive.ubuntu.com/ubuntu/pool/main/l/linux-source-2.6.20/linux-so...
> ) and no mention of mem.c or either of those two functions.
Hmmm -- I do see one thing with the /dev/mem driver that could
be an explanation. Maybe...
Prior to the read() call to /dev/mem, crash does an llseek() to
the target physical address, which gets stored in the open file
structure's file.f_pos member, which is a 64-bit loff_t. Then when
the subsequent read() call is made, the file.f_pos member gets
passed by reference to the /dev/mem driver's read_mem() function
via the "ppos" argument:
static ssize_t read_mem(struct file * file, char __user * buf,
size_t count, loff_t *ppos)
{
unsigned long p = *ppos;
ssize_t read, sz;
char *ptr;
if (!valid_phys_addr_range(p, count))
return -EFAULT;
But its value is then pulled from *ppos into a 32-bit unsigned long
"p" variable, which is what gets used from then on. So it looks like
the high 1-bit from a greater-than-4GB (0x100000000) physical address
would get stripped, and therefore would erroneously bypass the
valid_phys_addr_range() check.
So in your case, physical addresses from ~3GB-up-to-4GB would
be rejected, but those at and above 4GB would be inadvertently
accepted. However, if that were the case, the *wrong* physical address
would be accessed -- but your "module" reads seemingly return the correct
data! So I still don't get it...
I haven't tinkered with the 32-bit /dev/mem driver in years, because
Red Hat not only has the "high_memory" restriction, it also has a
devmem_is_allowed() function that further restricts /dev/mem to the
first 256 pages (1MB) of physical memory. (I note that upstream kernels
have recently added a CONFIG_STRICT_DEVMEM config option to do the same
thing.) And, FYI, the Red Hat /dev/crash "replacement-for-/dev/mem" driver
correctly reads *ppos into a u64.
So when you test this again on your live system, after printing the
module via "p <virtual-address-of-module>", do a vtop of the
<virtual-address-of-module>, take the translated-to physical address
and dump it to verify the contents. Like this:
crash> p modules
modules = $2 = {
next = 0xf8bf5904,
prev = 0xf8836004
}
crash> module 0xf8bf5900
struct module {
state = MODULE_STATE_LIVE,
list = {
next = 0xf8a60d84,
prev = 0xc06787b0
},
name = "crash"
mkobj = {
kobj = {
k_name = 0xf8bf594c "crash",
name = "crash",
kref = {
refcount = {
counter = 2
}
},
...
crash> vtop 0xf8bf5900
VIRTUAL PHYSICAL
f8bf5900 2412c900
...
crash> rd -p 2412c900 30
2412c900: 00000000 f8a60d84 c06787b0 73617263 ..........g.cras
2412c910: 00000068 00000000 00000000 00000000 h...............
2412c920: 00000000 00000000 00000000 00000000 ................
2412c930: 00000000 00000000 00000000 00000000 ................
2412c940: 00000000 00000000 f8bf594c 73617263 ........LY..cras
2412c950: 00000068 00000000 00000000 00000000 h...............
2412c960: 00000002 c06783e8 f8a60de4 c06783f4 ......g.......g.
2412c970: c06783e0 00000000 ..g.....
crash>
Lastly, try this set of crash commands on your live system:
rd -p 0
rd -p 0x20000000
rd -p 0x40000000
rd -p 0x60000000
rd -p 0x80000000
rd -p 0xa0000000
rd -p 0xb8000000
rd -p 0xc0000000
rd -p 0xe0000000
rd -p 0x100000000
rd -p 0x120000000
rd -p 0x140000000
Theoretically, anything at and above 0xb8000000 should fail.
> Let me try the kexec PAGE_OFFSET modification today or tomorrow and
> reply back on how it goes. If that produces no change I'll try do a
> re-run of the previous email's process with some more careful
> attention paid (that I get a vtop of everything and that my context
> examples are the same process).
OK fine...
Thanks,
Dave
15 years, 9 months
crash version 4.0-7.3 is available
by Dave Anderson
- Fix for nonsensical usage of the "set" command when running
against the xen hypervisor binary. If entered alone on the
command line, the command would cause a segmentation violation,
because there is no concept of a "context" in the xen hypervisor.
In addition, more reasonable error messages are displayed if
"set", "set -c <cpu>", "set -p", or "set <address>" are
attempted when running against a xen hypervisor.
(anderson(a)redhat.com)
- Fix for "bt" command on x86 architectures when the backtrace
starts on the hard IRQ stack. Without the patch, the backtrace
may not properly make the transistion back to the process
stack, and therefore not display the interrupt exception frame
or any kernel functions leading up to the interrupt.
(anderson(a)redhat.com)
- Fix for "search -k" option on some ia64 hardware, depending
upon the underlying physical memory layout. Without the patch
the command could fail prematurely with the error message:
"search: ia64_VTOP(a000000200000000): unexpected region 5 address".
(anderson(a)redhat.com)
- Fixes for the "bt" command when running against the xen hypervisor
binary. The "bt -o" option, and setting it to run by default with
"bt -O", would fail with the vmlinux-specific error message "bt:
invalid structure size: desc_struct" with a stack trace leading
to read_idt_table(); with the patch it will display the generic
error message "bt: -o option not supported or applicable on this
architecture or kernel". The "bt -e" or "bt -E" will also display
the same error message, as opposed to the command usage message.
Lastly, the "bt -R" option would cause a segmentation violation;
it has been fixed to work as it was designed.
(anderson(a)redhat.com)
- The "foreach" command has been removed from the set of commands
supported for usage with the xen hypervisor. If attempted, it
would always silently fail. (anderson(a)redhat.com)
- Fix for "irq -d" option when run on x86_64 xen kernels. Without the
patch it would indicate: "irq: invalid structure size: gate_struct"
and dump a stack trace leading to x86_64_display_idt_table(). Now it
will indicate that the -d option is not applicable.
(anderson(a)redhat.com)
- Avoid the symbolic translation of ia64 unity-mapped region 7 kernel
virtual addresses as they are displayed by the "bt -r" and "rd -[sS]"
commands. Without the patch, they are shown as "v+<offset>"
because "v" is an absolute symbol equal to 0xe000000000000000.
(anderson(a)redhat.com)
- Remove redundant storage of "swapper_pg_dir" symbol value during x86
initialization. (junkoi2004(a)gmail.com)
- Recognize the removal of the "jiffies" variable when running against
newer versions of the xen hypervisor by indicating "--:--:--" next
to the UPTIME display. (oda(a)valinux.co.jp)
- Fix to determine whether an x86 or x86_64 xen hypervisor was built
with PERCPU_SHIFT value of 12 or 13. Without the patch, crash
sessions running against a xen-3.3 hypervisor would fail during
initialization with the error message: "crash: cannot read elf note
core." (oda(a)valinux.co.jp)
Download from: http://people.redhat.com/anderson
15 years, 9 months
Re: [Crash-utility] Crash setup!
by Dave Anderson
----- "Bhaskar Jayaraman" <Bhaskar.Jayaraman(a)lsi.com> wrote:
> Dave, my apologies for being ambiguous, I forgot to mention how I
> installed xen-3.3.0; since an upgrade of the xen kernel, which came
> with the CentOS 5.2 DVD, to xen-3.3.0 would fail the xen python
> scripts, a workaround was employed.
> So we first install CentOS w/o Xen and then bring in the xen-3.3.0
> sources and install it on top of this. In this procedure the crash.ko
> driver doesn't seem to be getting installed.
> Now I'm facing two issues: -
>
> 1] I believe I will need the crash.ko driver to run the crash on a
> live kernel but I'm not able to find its source file in the linux
> sources that come with 3.3.0
As I've tried to stress in my previous responses, the Red Hat crash.ko module
is most likely *not* necessary in your case -- but more on that below...
With respect to the ramifications of applying xen-3.3.0 source code
(which includes Xensource's 2.6.18-based kernel, right?) on top of the
CentOS 5.2 source three, then it's to be expected that Xensource vmlinux
kernel doesn't include the /dev/crash driver -- that's a Red Hat only
concept.
>
> 2] I believe we have to build a debug kernel for crash to work with
> it. However when I enable the compile kernel with debug info in "make
> menuconfig", and make in the /xen-3.3.0/linux-2.6.18-xen.hg directory
> and do a make on /xen-3.3.0 directory, I keep getting an error which
> says: -
>
Sorry, I'm not going to be able to help you w/respect to upstream Xensource
kernel building. Never done it, and I don't suppose I ever will...
However, there are several upstream xen junkies on this list, and
they may be able to help you out with generating a debug-full vmlinux.
> make -C /home/user/xen-3.3.0/linux-2.6.18-xen.hg
> O=/home/user/xen-3.3.0/build-linux-2.6.18-xen_x86_64 modules
> Using /home/user/xen-3.3.0/linux-2.6.18-xen.hg as source for kernel
> /home/user/xen-3.3.0/linux-2.6.18-xen.hg is not clean, please run
> 'make mrproper'
> in the '/home/user/xen-3.3.0/linux-2.6.18-xen.hg' directory.
> make[5]: *** [prepare3] Error 1
> make[4]: *** [modules] Error 2
> make[3]: *** [modules] Error 2
> make[3]: Leaving directory
> `/home/user/xen-3.3.0/build-linux-2.6.18-xen_x86_64'
> make[2]: *** [build] Error 1
> make[2]: Leaving directory `/home/user/xen-3.3.0'
> make[1]: *** [linux-2.6-xen-install] Error 2
> make[1]: Leaving directory `/home/user/xen-3.3.0'
> make: *** [install-kernels] Error 1
BTW, did you do the preliminary "make mrproper" like it requests?
Anyway, getting back to the /dev/crash driver issue...
Especially given that you are running on an x86_64, the course of
least resistance is to utilize the built-in /dev/mem driver and forget
about trying to shoe-horn the Red Hat /dev/crash driver into place.
If /dev/mem doesn't work by default because the Xensource 2.6.18
vmlinux kernel has put restrictions on its use (like Red Hat does),
then just remove those restrictions and rebuild.
Dave
15 years, 9 months
Re: [Crash-utility] kernel-debuginfo & System.map
by Dave Anderson
----- "Jun Koi" <junkoi2004(a)gmail.com> wrote:
> Hi,
>
> I have a question on using crash:
> - Is it imperative to have System.map to use crash? It seems not to
> me, if we have a kernel debuginfo file. Is that correct?
That's absolutely correct.
The *only* reason for using a System.map file is if the vmlinux
file that you are putting on the crash command line is not
exactly the same as the vmlinux that generated the dumpfile
or is running on the live system.
> - Is it imperative to have a kernel debuginfo file to use crash
> (/boot/vmlinux-*)? Or it is OK to have System.map only?
Yes, you absolutely need a vmlinux file with debuginfo data.
Otherwise the crash session will kill itself immediately
with a "no debugging data available" error.
By adding a System.map file to the command line, you are implying
that the kernel symbol values found in in the command line vmlinux
file do not match those in the dumpfile or live system. So after
the "wrong" vmlinux file is passed to the embedded gdb module,
the crash utility goes into the gdb code throug a backdoor
and modifies all of the "minimal_symbol" data structures to
reflect the correct symbol values found in the System.map.
So for example, taking my live system, no arguments are necessary,
because the vmlinux file is found in a "known" location:
$ crash
crash 4.0-7.2
Copyright (C) 2002, 2003, 2004, 2005, 2006, 2007, 2008 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 6.1
Copyright 2004 Free Software Foundation, Inc.
GDB 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.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "x86_64-unknown-linux-gnu"...
KERNEL: /usr/lib/debug/lib/modules/2.6.18-92.el5/vmlinux
DUMPFILE: /dev/crash
CPUS: 8
DATE: Fri Oct 10 09:24:10 2008
UPTIME: 4 days, 00:07:36
LOAD AVERAGE: 0.25, 0.20, 0.18
TASKS: 244
NODENAME: crash.usersys.redhat.com
RELEASE: 2.6.18-92.el5
VERSION: #1 SMP Tue Apr 29 13:16:15 EDT 2008
MACHINE: x86_64 (1995 Mhz)
MEMORY: 1 GB
PID: 9033
COMMAND: "crash"
TASK: ffff810038e397e0 [THREAD_INFO: ffff81001c5f8000]
CPU: 4
STATE: TASK_RUNNING (ACTIVE)
crash>
But I can (for no good reason) enter the vmlinux file and its
associated System.map file, and as a result you'll see the
"patching ##### gdb minimal_symbol values" message:
$ crash /usr/lib/debug/lib/modules/2.6.18-92.el5/vmlinux /boot/System.map-2.6.18-92.el5
crash 4.0-7.2
Copyright (C) 2002, 2003, 2004, 2005, 2006, 2007, 2008 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 6.1
Copyright 2004 Free Software Foundation, Inc.
GDB 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.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "x86_64-unknown-linux-gnu"...
please wait... (patching 29117 gdb minimal_symbol values)
SYSTEM MAP: /boot/System.map-2.6.18-92.el5
DEBUG KERNEL: /usr/lib/debug/lib/modules/2.6.18-92.el5/vmlinux (2.6.18-92.el5)
DUMPFILE: /dev/crash
CPUS: 8
DATE: Fri Oct 10 09:25:27 2008
UPTIME: 4 days, 00:08:54
LOAD AVERAGE: 0.24, 0.20, 0.18
TASKS: 244
NODENAME: crash.usersys.redhat.com
RELEASE: 2.6.18-92.el5
VERSION: #1 SMP Tue Apr 29 13:16:15 EDT 2008
MACHINE: x86_64 (1995 Mhz)
MEMORY: 1 GB
PID: 9267
COMMAND: "crash"
TASK: ffff81003b6450c0 [THREAD_INFO: ffff8100394d0000]
CPU: 2
STATE: TASK_RUNNING (ACTIVE)
crash>
The use of a System.map file is mainly a remnant of the "old days"
when distros typically didn't make a debuginfo vmlinux file
available. So the kernel src.rpm would have to be rebuilt after
the fact, with -g added to the kernel Makefile's CFLAGS. But
doing that would/could alter the symbol values in the rebuilt
debuginfo vmlinux such that they wouldn't match up exactly to
those in the original vmlinux.
It should be that the data structure declarations in the "wrong" vmlinux
are presumed to be correct, or correct enough such that the crash session
will work. If any crucial data structures that crash depends upon
have been modified, then all bets are off.
Dave
15 years, 9 months
redundant code
by Jun Koi
Hi,
Function x86_init_kernel_pgd() in x86.c has a redundant code that
should be removed.
x86_init_kernel_pgd(void)
{
int i;
ulong value;
value = symbol_value("swapper_pg_dir"); // <--- THIS IS NOT NECESSARY
if (XEN())
get_symbol_data("swapper_pg_dir", sizeof(ulong), &value);
else
value = symbol_value("swapper_pg_dir");
for (i = 0; i < NR_CPUS; i++)
vt->kernel_pgd[i] = value;
}
Thanks,
J
15 years, 9 months
Re: [Crash-utility] Crash setup!
by Dave Anderson
----- "Bhaskar Jayaraman" <Bhaskar.Jayaraman(a)lsi.com> wrote:
> Dave, I somehow didn't receive your previous thread and had to look it
> up on the mailing list website. I'm using the following configuration:
> -
> Dell T7400 with VT and VT-d enabled.
> CentOS 5.2 with 2.6.18 kernel
OK, I see that the CentOS 5.2 kernel-2.6.18-92.el5.src.rpm package contains
contains the crash driver, and in that package both kernel-2.6.18-x86_64.config
and kernel-2.6.18-x86_64-xen.config still have CONFIG_CRASH=m set.
But that's not surprising given that CentOS 5 is supposed to be identical
to RHEL5.
>
> I guess the default kernel doesn't build with crash and other
> debugging options. However when I do a "make menuconfig" I didn't see
> any option specific to crash in it.
When you say "default kernel", what kernel are you referring to?
If you're still talking about Centos kernel-2.6.18-92.el5.src.rpm, all you
have to do is install the kernel-2.6.18-92.el5.src.rpm, go the relevant
SPECS directory, and enter "rpmbuild -ba --target x86_64 kernel-2.6.spec".
It's built with debugging enabled, and creates a set of kernel debuginfo
packages that can be installed.
> So I applied the patch from
> sourcefourge but it is for 2.6.10 kernel. I am somehow trying to
> compile the code with my own hacks but if you have a better idea let
> me know.
Sorry, I have *no* idea what you're talking about w/respect to the
"patch from sourceforge"...
> I still haven't started compiling the crash utils.
Well, at least that's trivial. The simplest way to do that
is to just download the latest tar.gz file from my web site.
$ tar xzf crash-4.0-7.2.tar.gz
...
$ cd crash-4.0-7.2
$ make
>
> Since 2.6.18-92-el5 contains crash in it I was wondering if I simply
> get its sources from the CD and try and compile with my kernel but I
> got involved in trying to fix the 2.6.10 kernel so I have left it for
> later. I specifically need to compile crash with 2.6.18 right now and
> maybe later on for different versions of the kernel. Let me know what
> are your thoughts on it and if there's a place where I can find crash
> sources for all kernel flavors.
Now I'm getting more confused. When you say "compile crash with 2.6.18",
are you talking about the crash utility? The crash utility is designed
to be run on any kernel "flavor". You just have to compile it on the
host machine where you want to run it. It has no kernel version dependencies
because it is designed to maintain backwards compatibility while being
updated regularly to "keep up" with upstream kernel changes.
If you're still referring to the /dev/crash kernel driver, and given
that you are capable of rebuilding whatever kernel you're going to run
to run with, then I strongly suggest just using the /dev/mem driver.
I'm presuming that you're running the 64-bit x86_64 kernel given the
hardware you're running on. With a 64-bit kernel, there's no benefit
in trying to backport the Red Hat /dev/crash driver into your kernel.
Dave
>
> Thanks,
> Bhaskar.
> ________________________________________
> From: crash-utility-bounces(a)redhat.com
> [crash-utility-bounces(a)redhat.com] On Behalf Of Dave Anderson
> [anderson(a)redhat.com]
> Sent: Tuesday, October 07, 2008 11:43 AM
> To: Discussion list for crash utility usage, maintenance and
> development
> Subject: Re: [Crash-utility] Crash setup!
>
> > But the /dev/crash driver does require small modifications to the
> kernel source,
> > primarily to EXPORT_SYMBOL_GPL() the page_is_ram() function.
>
> Interesting -- FWIW, the EXPORT_SYMBOL_GPL() requirement for
> page_is_ram()
> may no longer be required if an analogous, static, version of
> page_is_ram()
> were to be written into the crash driver itself -- and that static
> version
> could use the e820_any_mapped() function, which is EXPORT_SYMBOL_GPL()
> in
> the upstream kernel:
>
> /*
> * This function checks if any part of the range <start,end> is
> mapped
> * with type.
> */
> int
> e820_any_mapped(u64 start, u64 end, unsigned type)
> {
> int i;
> for (i = 0; i < e820.nr_map; i++) {
> const struct e820entry *ei = &e820.map[i];
> if (type && ei->type != type)
> continue;
> if (ei->addr >= end || ei->addr + ei->size <=
> start)
> continue;
> return 1;
> }
> return 0;
> }
> EXPORT_SYMBOL_GPL(e820_any_mapped);
>
> For that matter, e820_any_mapped() is also in RHEL5. But it was not
> in the 2.6.9-based RHEL4 kernel, which was what the RHEL5 version of
> the
> crash driver was based upon.
>
> But RHEL5 also has modified the x86-only page_is_ram() to check for
> efi_enabled,
> and if it's set, to use the "memmap" efi_memory_map instead of the
> e820 map.
> Although, that's not done upstream.
>
> Anyway, just another data point...
>
> Dave
>
>
>
> --
> Crash-utility mailing list
> Crash-utility(a)redhat.com
> https://www.redhat.com/mailman/listinfo/crash-utility
>
> --
> Crash-utility mailing list
> Crash-utility(a)redhat.com
> https://www.redhat.com/mailman/listinfo/crash-utility
15 years, 9 months
kernel-debuginfo & System.map
by Jun Koi
Hi,
I have a question on using crash:
- Is it imperative to have System.map to use crash? It seems not to
me, if we have a kernel debuginfo file. Is that correct?
- Is it imperative to have a kernel debuginfo file to use crash
(/boot/vmlinux-*)? Or it is OK to have System.map only?
Thanks,
J
15 years, 9 months
