Re: [Crash-utility] user-space enhancements
by Dave Anderson
----- "James Bradshaw" <jbradsha(a)enterasys.com> wrote:
> One of the items in the bug list is the following:
>
> DESCRIPTION:
> User space enhancements:
> - show user space stack backtrace, if present in the dump file,
> - ability to link user space namelist (debug object files),
>
> RESOLUTION STATUS: TBD
>
> Is anyone currently working on this?
The items in the TODO list, with the exception of the first
one about the "search" command, are all essentially "wish-list"
items. They were originally requested to be put there by IBM
several years ago when the http://people.redhat.com/anderson
site was instantiated as the "upstream" source of the crash
utility.
The only item that I'm aware of that somebody is actually looking
into is the one regarding "local variables", where I believe the
guy looking into it is part of the IBM LTC in India. I don't
expect much to come out of it, though, because for one thing
it presumes that the crash utility's backtrace frame information
is etched in stone -- and with the exception of ia64 which has
unwind information actually built into the kernel -- the backtrace
is essentially a "best-guess" operation. So trying to pull local
arguments (or function arguments for that matter) from a
dubious source doesn't make a whole lot of sense.
As far as a user-space backtrace, I still think the way to go
is to work on creating a core dump file of the requested task,
and then use gdb externally on that core file, completely outside
of the crash utility. Trying to overload the crash utility with
a bunch of user-space stuff is something I don't have a lot of
interest in.
Dave
15 years, 11 months
Re: [Crash-utility] fd_init()
by Dave Anderson
----- "James Bradshaw" <jbradsha(a)enterasys.com> wrote:
> In fd_init() in filesys.c the namelist file is opened and pc->nfd is
> initialized:
>
>
> if ((pc->nfd = open(pc->namelist, O_RDONLY)) < 0)
> error(FATAL, "%s: %s\n", pc->namelist, strerror(errno));
> else {
> close(pc->nfd);
> pc->nfd = -1;
> }
>
>
> In the event of a successful open the else clause is executed, and the
> file that was just opened is closed. Why?
In the case of normal crash usage, the pc->nfd is basically
a throw-away file descriptor. It's just there to kill off the
crash session immediately if the vmlinux file cannot be opened
for whatever reason. The crash utility itself doesn't do an
open() call on the vmlinux file, but rather it passes that
responsibility down to the embedded gdb module, which essentially
is invoked as "gdb vmlinux".
The pc->nfd descriptor used to be used by the "remote" capability
of the crash utility, where the vmcore (and perhaps the vmlinux)
files existed on a remote system. If the vmlinux was remote, it
would be copied to a local version that was handled by that pc->nfd
during the copy operation. But anyway, that's all deprecated
code, but I've never gotten around to ripping it all out because
it has tentacles in places other than "remote.c". But I think that
it's most likely a (harmless) no-op at this point.
Dave
15 years, 11 months
fd_init()
by Bradshaw, James
In fd_init() in filesys.c the namelist file is opened and pc->nfd is initialized:
if ((pc->nfd = open(pc->namelist, O_RDONLY)) < 0)
error(FATAL, "%s: %s\n", pc->namelist, strerror(errno));
else {
close(pc->nfd);
pc->nfd = -1;
}
In the event of a successful open the else clause is executed, and the file that was just opened is closed. Why?
James T. Bradshaw
Firmware Engineer
Enterasys Networks
50 Minuteman Rd.
Andover, MA 01810
USA
Tel. (978) 684-1544
15 years, 11 months
searchable crash utility archives/nr_swapfiles
by Bradshaw, James
I apologize for this newbie question, but is there a way to search the crash archives without having to manually download each month's text file?
Specifically, I'm looking for any information on the following error message
crash: cannot resolve: "nr_swapfiles"
[jbradsha-linux](jbradsha)318$ ./crash -v
crash 4.0-7.4
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 "i686-pc-linux-gnu".
I'm not using any swap space on my target; is there a way to tell crash that?
Thanks.
James T. Bradshaw
Firmware Engineer
Enterasys Networks
50 Minuteman Rd.
Andover, MA 01810
USA
Tel. (978) 684-1544
15 years, 11 months
crash version 4.0-7.5 is available
by Dave Anderson
Changelog for crash version 4.0-7.5:
- Fix for "kmem -i" and "kmem -p" on 2.6.26 x86 CONFIG_SPARSEMEM
PAE kernels to account for the change in value of SECTION_SIZE_BITS.
(oomichi(a)mxs.nes.nec.co.jp)
- Fix for "bt -[tT]" options on x86 architectures when the backtrace
starts on the hard IRQ stack. Without the patch, the backtrace
may not properly make the transition back to the process stack.
(anderson(a)redhat.com)
- Fix for the "bt" command when run on a xen hypervisor in which the
backtrace leads to either "process_softirqs" or "page_fault".
Without the patch, the backtrace indicates: "bt: cannot resolve stack
trace", and then the recovery code terminates the command with the
nonsensical error message: "bt: invalid structure size: task_struct".
(oda(a)valinux.co.jp, anderson(a)redhat.com)
- Fix for the "kmem -[sS]" options that could cause a segmentation
violation or bogus "bad slab pointer" and "bad inuse counter" error
messages. Reported on 2.6.25-based CONFIG_DEBUG_SLAB kernels, but
could conceivably occur on any kernel with a kmem_cache.nodelists[]
array. (anderson(a)redhat.com)
- Fix for a bug in the SIAL extension when dealing with bitfields.
(olaf(a)sgi.com, hedi(a)sgi.com)
- Fix for the "files" command when run on 2.6.25 and later kernels,
which would either fail with an "invalid kernel virtual address"
error of type "fill_dentry_cache", or would show nonsensical/garbage
"ROOT" and "CWD" pathnames. This was due to the change in format
of the kernel's fs_struct. (anderson(a)redhat.com)
- Addition of a new "null-stop" environment variable that can be turned
on/off with the "set" command. It simply controls the embedded gdb's
"null-stop" print setting, which, if on, will stop printing character
arrays when the first NULL is encountered. The default setting is
still "off", so there will be no behavioral changes unless it is
turned on during runtime or in .crashrc files.
(anderson(a)redhat.com)
- Fix for the builtin "g" alias, which would fail with an "Ambiguous
command" error from the embedded gdb module.
(anderson(a)redhat.com)
- Fix to handle the 2.6.27 kernel's change of the module structure's
num_symtab, core_size and core_text_size members from long to int.
Without the patch, initialization-time failures would result when
running against 64-bit big-endian kernels, and potentially on little-
endian 64-bit kernels. (bwalle(a)suse.de)
- Implement support for the /dev/crash driver being built into x86 or
x86_64 Red Hat kernels with the restricted /dev/mem driver. Without
the patch, if the kernel was built with CONFIG_CRASH configured as
"y" instead of "m", and crash was run against the resultant live
kernel, it would fail during initialization attempting to use the
restricted /dev/mem device. (anderson(a)redhat.com)
- If the /dev/crash driver module has been loaded prior to a live crash
session, then it will not be unloaded when the crash session exits.
Normally the module gets loaded by the crash utility during its
initialization on a live system, and then unloaded when the crash
session exits, regardless whether the module was loaded by the crash
utility itself or if it was pre-loaded manually. However, if a cpu
subsequently hangs, then a live crash session attempt would also hang
when it tries to load the module. This patch will allow the crash.ko
module to be pre-loaded -- for example during kernel boot-time -- and
if a cpu subsequently hangs, a live crash session can be initiated to
investigate the problem. (anderson(a)redhat.com)
- Fix to recognize the 2.6.25 re-naming of the x86 user_regs_struct
structure members. Without the patch, running against a kdump
dumpfile would fail with the error: "crash: invalid structure member
offset: user_regs_struct_ebp". (anderson(a)redhat.com)
- Fix for initialization-time failure when running against 2.6.27
x86_64 xen kernels, which indicate "crash: cannot resolve: end_pfn".
(bwalle(a)suse.de)
- Fix for initialization-time failure when running against Xen 4.4
hypervisor binaries, which indicate "crash: invalid structure member
offset: domain_is_polling". (bwalle(a)suse.de)
- Added a new "p -u" option, which indicates that the gdb expression
argument evaluates to a user virtual address in the current context.
This option could be used, for example, if a known kernel data
structure exists at user virtual address in the current context,
or if the debuginfo data of a user program were loaded into the
crash session via the gdb "add-symbol-file" command.
(anderson(a)redhat.com)
- Fix for "bt -a" command when running against the xen hypervisor where
the number of physical cpus outnumber the MAX_VIRT_CPUS value for the
processor type. Without the patch on such a system, "bt -a" would
fail after displaying backtraces for the first 32 (MAX_VIRT_CPUS)
pcpus with the the error message: "bt: invalid vcpu". The patch also
corrects the "vcpus" command output to show the vcpus associated with
pcpus 32 through 63, and the "doms" command output to show the second
idle domain associated with pcpus 32 through 63.
(oda(a)valinux.co.jp)
- Fix for the display of the processor speed on IBM Power6 hardware.
Without the patch, "MACHINE: ppc64 (unknown Mhz)" would be displayed
upon initialization and by the "sys" command.
(sachinp(a)in.ibm.com, acv(a)linux.vnet.ibm.com)
Download from: http://people.redhat.com/anderson
15 years, 11 months
Re: [Crash-utility] user-space enhancements
by Dave Anderson
----- "James Bradshaw" <jbradsha(a)enterasys.com> wrote:
> Thanks. I gather that lkcd/lcrash was an earlier effort unrelated to
> crash. Is that correct?
The LKCD project consisting of both the LKCD kernel patch and its
associated "lcrash" user-space command, was first posted by SGI in 1999,
literally within days of a parallel effort done by Mission Critical Linux
when we posted our "mcore" kernel patch and our original "crash"
utility. After the demise of Mission Critical Linux in 2002, I was hired
by Red Hat, and brought the crash utility with me.
While still at Mission Critical, however, I did add support for the
LKCD dumpfile format in the crash utility, and the LKCD developers and
I have passed stuff back-and-forth over the years.
Anyway, neither mcore or the LKCD kernel patches were ever adopted upstream.
After what seems to have been an eternity, finally the kdump facility
was accepted. It seems highly unlikely that the kdump facility
would ever be modified to also capture swap contents, although I
suppose anything's possible.
That all being said, given the core-dump masking support in the
current kernels, you can now set /proc/<pid>/coredump_filter to
pretty much strip almost everything out of the user core file, while
still being able to debug the basics. Even when filtering out
anonymous private and shared memory pages (which strips out user
stack pages), the core dump is still usable by gdb, and will at
least pinpoint the last known location.
Dave
>
> -----Original Message-----
> From: crash-utility-bounces(a)redhat.com
> [mailto:crash-utility-bounces@redhat.com] On Behalf Of Michael
> Holzheu
> Sent: Friday, December 05, 2008 4:35 AM
> To: Discussion list for crash utility usage, maintenance and
> development
> Cc: Dan Stein
> Subject: RE: [Crash-utility] user-space enhancements
>
> Am Donnerstag, den 04.12.2008, 14:06 -0800 schrieb Castor Fu:
> > There was a group at IBM (Stefan Schlosser <sschloss(a)de.ibm.com>)
> > a few years ago which set up stuff to generate
> > a elf corefile for a user space process for lcrash.
>
> Stefan did that as diploma thesis in our department at IBM. The ugly
> part was the swap file handling. The swap files had to be saved after
> a
> dump in order to access all user space memory. We added the save
> function in lcrash:
>
> lcrash -S <swapdump>
>
> to generate a dump-file containing all used swapped out pages of all
> swap areas.
>
> And we added an extra parameter <swapdump> when starting lcrash to
> analyze the dump:
>
> lcrash map.x dump.x kerntypes.x <swapdump>
>
> Here the posting on the lkcd mailing list:
>
> http://sourceforge.net/mailarchive/message.php?msg_id=OF7160ABF7.B54F4970...
>
> But the code was never integrated officially in lcrash.
>
> Michael
>
> --
> 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, 11 months
Re: [Crash-utility] "crash: cannot allocate any more memory!" for 2.6.27.4
by Dave Anderson
----- "Dheeraj Sangamkar" <dheerajrs(a)gmail.com> wrote:
> On the same machine, I am unable to live-debug the running kernel.
> Here is the error I get. Please let me know if there is something I
> can do to get crash working.
>
> /dheeraj/crash/crash-4.0-7.4 # crash -d 255
> /boot/System.map-2.6.27.4-2-default
> /root/dheeraj/linux-2.6.27.4-2.1/vmlinux
>
> crash 4.0-7.4
> 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.
>
> crash: diskdump / compressed kdump: dump does not have panic dump
> header
> get_live_memory_source: /dev/mem
> crash: pv_init_ops exists: ARCH_PVOPS
> _text: ffffffff80200000 Kernel code: 200000 -> phys_base: 0
>
> gdb /root/dheeraj/linux-2.6.27.4-2.1/vmlinux
> 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"...
> GETBUF(248 -> 0)
> GETBUF(1500 -> 1)
>
> FREEBUF(1)
> FREEBUF(0)
> <readmem: ffffffff804be660, KVADDR, "kernel_config_data", 32768,
> (ROE), 1ae5040>
> /dev/mem: Operation not permitted
> crash: read(/dev/mem, 4be660, 2464): 4294967295 (ffffffff)
> crash: read error: kernel virtual address: ffffffff804be660 type:
> "kernel_config_data"
> WARNING: cannot read kernel_config_data
> GETBUF(248 -> 0)
> FREEBUF(0)
> GETBUF(16 -> 0)
> <readmem: ffffffff80a14800, KVADDR, "cpu_possible_map", 16, (ROE),
> a49160>
> /dev/mem: Operation not permitted
> crash: read(/dev/mem, a14800, 16): 4294967295 (ffffffff)
> crash: read error: kernel virtual address: ffffffff80a14800 type:
> "cpu_possible_map"
> WARNING: cannot read cpu_possible_map
> <readmem: ffffffff80872710, KVADDR, "cpu_present_map", 16, (ROE),
> a49160>
> /dev/mem: Operation not permitted
> crash: read(/dev/mem, 872710, 16): 4294967295 (ffffffff)
> crash: read error: kernel virtual address: ffffffff80872710 type:
> "cpu_present_map"
> WARNING: cannot read cpu_present_map
> <readmem: ffffffff80846c90, KVADDR, "cpu_online_map", 16, (ROE),
> a49160>
> /dev/mem: Operation not permitted
> crash: read(/dev/mem, 846c90, 16): 4294967295 (ffffffff)
> crash: read error: kernel virtual address: ffffffff80846c90 type:
> "cpu_online_map"
> WARNING: cannot read cpu_online_map
> FREEBUF(0)
> <readmem: ffffffff80a74400, KVADDR, "xtime", 16, (FOE), a0d2f0>
> /dev/mem: Operation not permitted
> crash: read(/dev/mem, a74400, 16): 4294967295 (ffffffff)
> crash: read error: kernel virtual address: ffffffff80a74400 type:
> "xtime"
Live system analysis is impossible if /dev/mem won't allow you
to read physical memory. Each read attempt above results in an
"Operation not permitted" (EPERM) error.
They fail because of a pain-in-the-ass CONFIG_STRICT_DEVMEM configuration
option that was recently added to upstream kernels. When the crash
utility makes a read() from /dev/mem, it ends up in the kernel's
drivers/char/mem.c driver, and proceeds like so:
read_mem()
range_is_allowed()
devmem_is_allowed()
Here is the call in read_mem() that returns the EPERM:
if (!range_is_allowed(p >> PAGE_SHIFT, count))
return -EPERM;
Here are the two versions of range_is_allowed() in drivers/char/mem.c,
which depend upon CONFIG_STRICT_DEVMEM:
#ifdef CONFIG_STRICT_DEVMEM
static inline int range_is_allowed(unsigned long pfn, unsigned long size)
{
u64 from = ((u64)pfn) << PAGE_SHIFT;
u64 to = from + size;
u64 cursor = from;
while (cursor < to) {
if (!devmem_is_allowed(pfn)) {
printk(KERN_INFO
"Program %s tried to access /dev/mem between %Lx->%Lx.\n",
current->comm, from, to);
return 0;
}
cursor += PAGE_SIZE;
pfn++;
}
return 1;
}
#else
static inline int range_is_allowed(unsigned long pfn, unsigned long size)
{
return 1;
}
#endif
And the call to devmem_is_allowed() above ends up here, where only the
first 256 pages (1MB) of physical memory is accessible:
int devmem_is_allowed(unsigned long pagenr)
{
if (pagenr <= 256)
return 1;
if (!page_is_ram(pagenr))
return 1;
return 0;
}
So that makes /dev/mem useless for the crash utility...
Bernhard Walle made a valiant attempt to make this a run-time configurable
rather than a compile-time config option,
http://lkml.org/lkml/2008/11/16/117
But the LKML thread went off into the weeds arguing whether the CONFIG_STRICT_DEVMEM
imposition itself should be ripped out, rather than putting lipstick on a pig.
And so it got nowhere...
This same 256-page restriction has been in place in RHEL4 and RHEL5 kernels
as well, because the same guy who managed to push it upstream formerly worked
at Red Hat, and convinced the powers-that-be here that /dev/mem was a security
hole. As a result, I had to write a whole new physical memory-access device
driver (/dev/crash) that is a read-only "misc" driver that the crash utility
automatically loads when run on a live system. But it's only available in
the Red Hat RHEL4 and RHEL5 distribution, although it can be ported easily
enough.
So you've got 3 options:
1. Rebuild your kernel with CONFIG_STRICT_DEVMEM turned off.
2. Port the RHEL /dev/crash driver to your kernel. I did suggest that
in another crash-utility thread here:
https://www.redhat.com/archives/crash-utility/2008-October/msg00057.html
3. Write a kprobe module that forces devmem_is_allowed() to return 1 always:
http://www.redhat.com/archives/crash-utility/2008-March/msg00036.html
If you've got the power, obviously #1 is the best option. But if you cannot
change kernels, probably the kprobe option #3 is easier than porting the RHEL
/dev/crash driver. Check Documentation/kprobes.txt file and the samples/kprobes
directory in your kernel build tree, and then use the RHEL kprobe example
I put in the thread referenced in #3 above. If that won't work (and I don't
know why it wouldn't), then you can always port the RHEL /dev/crash driver
that's attached to the thread reference in #2 above.
Dave
15 years, 12 months
user-space enhancements
by Bradshaw, James
One of the items in the bug list is the following:
DESCRIPTION:
User space enhancements:
- show user space stack backtrace, if present in the dump file,
- ability to link user space namelist (debug object files),
RESOLUTION STATUS: TBD
Is anyone currently working on this?
James T. Bradshaw
Firmware Engineer
Enterasys Networks
50 Minuteman Rd.
Andover, MA 01810
USA
Tel. (978) 684-1544
15 years, 12 months
Re: [Crash-utility] "crash: cannot allocate any more memory!" for 2.6.27.4
by Dave Anderson
----- "Dheeraj Sangamkar" <dheerajrs(a)gmail.com> wrote:
> Hi,
> I am able to use crash to debug a crash dump generated when I initiate
> the crash using the sysrq-trigger in the /proc directory.
> But when I try to use crash to debug a kernel vmcore generated due to
> the insertion of my module, I get the error below.
>
> Please let me know if I am doing anything wrong or if you think that
> the dump is corrupted. I use kdump for dump collection.
> I am using a 2.6.27.4-2-default kernel.
> ---------------------------------------------------------------------------------------------------------------------------------
> /var/crash/2008-12-01-18:40 # crash System.map-default vmlinux vmcore
If the vmlinux file is the same kernel as is running on your live system,
then do not use the "System-map-default" file. If you're not sure, then
just run "crash vmlinux vmcore", and if the vmlinux file does not match
you will get an error message.
That being said, it's highly unlikely that it is the problem at hand -- but
please avoid using System.map files if at all possible.
>
> crash 4.0-7.4
> 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... (gathering module symbol data) buf_1K_used: 299
> buf_2K_used: 1
> buf_4K_used: 155
> buf_8K_used: 1
> buf_32K_used: 2
> buf_1K_ovf: 0
> buf_2K_ovf: 0
> buf_4K_ovf: 0
> buf_8K_ovf: 0
> buf_32K_ovf: 0
> buf_1K_maxuse: 2 of 10
> buf_2K_maxuse: 1 of 10
> buf_4K_maxuse: 1 of 5
> buf_8K_maxuse: 1 of 5
> buf_32K_maxuse: 1 of 1
> buf_inuse[5]: [0][0][0][0][1]
> smallest: 16
> largest: 21474854400 <=== allocation of this buffer size failed
> embedded: 2
> max_embedded: 2
> mallocs: 0
> frees: 0
> reqs/total: 459/21475603516.0
> average size: 46787807.2
>
> crash: cannot allocate any more memory!
While gathering the symbols of the currently-loaded kernel modules,
something has caused crash to attempt a bizarre memory allocation of
21474854400 (20GB+), which dutifully failed.
Most likely something has changed in the struct module that has caused
crash to go off into the weeds. It may very well be fixed in a currently-
queued patch that Bernhard Walle sent in:
[Crash-utility] [PATCH] Fix module size and num_symtab for 2.6.27
https://www.redhat.com/archives/crash-utility/2008-November/msg00000.html
Try applying that patch to 4.0-7.4 and see what happens.
Dave
15 years, 12 months
