handling missing kdump pages in diskdump format
by Bob Montgomery
I've been experimenting with the makedumpfile utility for kdump on ia64.
One of my experiments was to verify that a page that should have been
missing indeed was missing. I used crash 4.0-3.8 to look for a user
page that should have been omitted from the dump.
crash> x/xg 0xe0000040fc00c000
0xe0000040fc00c000: 0x0000000000000000
On a full dump from makedumpfile as well as on a straight copy of
vmcore, crash reports this:
crash> x/xg 0xe0000040fc00c000
0xe0000040fc00c000: 0x00010102464c457f
The dumpfiles created by makedumpfile appear to crash as diskdump files,
and crash appears to excuse missing pages and report 0x0 contents here:
diskdump.c:read_diskdump, line 454:
if (!page_is_dumpable(pfn)) {
memset(bufptr, 0, cnt);
return cnt;
Shouldn't there be some indication that a requested page is missing as
opposed to being legitimately full of zeros?
Bob Montgomery
17 years, 4 months
Re: [Crash-utility] crash can not read ia64 lkcd v9 dump
by Alan Tyson
> But first I'll fix the header format which _is_ different in crash and
> our SLES9 kernel (and klcdutils), and if it then doesn't work I'll
> come back to the system maps.
>
> Thanks for your help!
>
> Regards,
> Bernhard
Bernhard,
There are two changes rquired to fix up the header format for SLES9.
One is NR_CPUS and the other is a missing fiels in the dump header.
This may be of help, it' what I've been using:
# cat sles9.patch
diff -Nurp crash-4.0-3.13/defs.h crash-4.0-3.13-sles9/defs.h
--- crash-4.0-3.13/defs.h 2006-11-27 18:41:27.000000000 +0000
+++ crash-4.0-3.13-sles9/defs.h 2006-12-01 14:55:39.727248386 +0000
@@ -68,7 +68,7 @@
#define NR_CPUS (32)
#endif
#ifdef IA64
-#define NR_CPUS (1024)
+#define NR_CPUS (128)
#endif
#ifdef PPC64
#define NR_CPUS (128)
diff -Nurp crash-4.0-3.13/lkcd_fix_mem.h crash-4.0-3.13-sles9/lkcd_fix_mem.h
--- crash-4.0-3.13/lkcd_fix_mem.h 2006-11-27 18:41:27.000000000 +0000
+++ crash-4.0-3.13-sles9/lkcd_fix_mem.h 2006-12-01 14:55:39.727248386 +0000
@@ -266,6 +266,9 @@ typedef struct _dump_header_asm_s {
/* the size of this header (in case we can't read it) */
uint32_t dha_header_size;
+ /* load address of the kernel (added by sles9 patch) */
+ uint64_t dha_kernel_addr;
+
/* pointer to pt_regs */
// struct pt_regs *dha_pt_regs; // version 4 changed this
uint64_t dha_pt_regs;
diff -Nurp crash-4.0-3.13/.rh_rpm_package crash-4.0-3.13-sles9/.rh_rpm_package
--- crash-4.0-3.13/.rh_rpm_package 1970-01-01 01:00:00.000000000 +0100
+++ crash-4.0-3.13-sles9/.rh_rpm_package 2006-12-01 14:55:39.733107761 +0000
@@ -0,0 +1 @@
+4.0-3.13-sles9
I hope this helps.
Regards,
Alan Tyson, HP Services.
17 years, 6 months
RE: [Crash-utility] crash-4.0-3.14-sym.3.patch (was: modules and data /bss initialization)
by Castor Fu
Hi Dave!
Sorry about the regression.
I looked further through the code, and have modified it to only add the
symbols
for which it has actually identified a matching section, and to do it in
a way
which supports whatever sections are defined.
This doesn't explain why a match isn't being found in the ia64 case, but
should
at least avoid the regression in the s390x case.
I've also attached a test which one could run which dumps output which
might
help me fix things by tracing through loading the 'md5' module.
By default the new code is off, as requested, and can be forced with
a '-l' option to 'mod', e.g.
crash> mod -l -s md5
Thanks again for the testing, and hopefully this will work for most
people.
It would be great if someone could send me output from the rarer
platforms like ppc64 or 390 if it doesn't work.
Happy New Year!
-castor
________________________________
From: crash-utility-bounces(a)redhat.com
[mailto:crash-utility-bounces@redhat.com] On Behalf Of Dave Anderson
Sent: Tuesday, December 19, 2006 7:44 AM
To: crash-utility(a)redhat.com; Castor Fu
Subject: [Crash-utility] crash-4.0-3.14-sym.3.patch (was: modules and
data /bss initialization)
Hi Castor,
While I have had some success with this patch on x86 and
x86_64 machines, I haven't been so fortunate with other
architectures.
On ia64 machines for example, it quite often is unable
to determine the .data segment address of a module, leaving
it as 0, so there is no improvement over the current way it works.
On the s390x, it actually causes a pretty serious regression.
For example without the patch, here are the data addresses
of the ext3 module before and after it gets loaded:
$ /usr/bin/crash -s vmlinux-2.6.18-1.2767.el5
crash> sym -m ext3 | grep "([dD])"
208bfea0 (d) ext3_dir_operations
208bff88 (d) ext3_file_operations
208c0070 (d) ext3_ordered_aops
208c00e0 (d) ext3_writeback_aops
208c0150 (d) ext3_journalled_aops
208c01c0 (d) ext3_xattr_handler_map
208c01f8 (d) ext3_file_inode_operations
208c02a0 (d) ext3_dir_inode_operations
208c0348 (d) ext3_special_inode_operations
208c03f0 (d) ext3_fs_type
208c0430 (d) ext3_sops
208c04d8 (d) ext3_export_ops
208c0508 (d) ext3_qctl_operations
208c0560 (d) ext3_quota_operations
208c05c0 (d) ext3_symlink_inode_operations
208c0668 (d) ext3_fast_symlink_inode_operations
208c0710 (d) ext3_xattr_handlers
208c0740 (d) tokens
208c0a40 (d) ext3_xattr_user_handler
208c0a60 (d) ext3_xattr_trusted_handler
208c0a80 (d) ext3_xattr_acl_access_handler
208c0aa0 (d) ext3_xattr_acl_default_handler
208c0ac0 (d) ext3_xattr_security_handler
208c0b00 (d) __this_module
crash> mod -s ext3
MODULE NAME SIZE OBJECT FILE
208c0b00 ext3 200208
/lib/modules/2.6.18-1.2767.el5/kernel/fs/ext3/ext3.ko
crash> sym -m ext3 | grep "([dD])"
208bfea0 (d) ext3_dir_operations
208bff88 (d) ext3_file_operations
208c0070 (d) ext3_ordered_aops
208c00e0 (d) ext3_writeback_aops
208c0150 (d) ext3_journalled_aops
208c01c0 (d) ext3_xattr_handler_map
208c01f8 (d) ext3_file_inode_operations
208c02a0 (d) ext3_dir_inode_operations
208c0348 (d) ext3_special_inode_operations
208c03f0 (d) ext3_fs_type
208c0430 (d) ext3_sops
208c04d8 (d) ext3_export_ops
208c0508 (d) ext3_qctl_operations
208c0560 (d) ext3_quota_operations
208c05c0 (d) ext3_symlink_inode_operations
208c0668 (d) ext3_fast_symlink_inode_operations
208c0710 (d) ext3_xattr_handlers
208c0740 (d) tokens
208c0a40 (d) ext3_xattr_user_handler
208c0a60 (d) ext3_xattr_trusted_handler
208c0a80 (d) ext3_xattr_acl_access_handler
208c0aa0 (d) ext3_xattr_acl_default_handler
208c0ac0 (d) ext3_xattr_security_handler
208c0b00 (d) __this_module
crash>
That looks fine...
However, with the patch applied, I get the following behavior:
$ crash*14/crash -s vmlinux-2.6.18-1.2767.el5
crash> sym -m ext3 | grep "([dD])"
208bfea0 (d) ext3_dir_operations
208bff88 (d) ext3_file_operations
208c0070 (d) ext3_ordered_aops
208c00e0 (d) ext3_writeback_aops
208c0150 (d) ext3_journalled_aops
208c01c0 (d) ext3_xattr_handler_map
208c01f8 (d) ext3_file_inode_operations
208c02a0 (d) ext3_dir_inode_operations
208c0348 (d) ext3_special_inode_operations
208c03f0 (d) ext3_fs_type
208c0430 (d) ext3_sops
208c04d8 (d) ext3_export_ops
208c0508 (d) ext3_qctl_operations
208c0560 (d) ext3_quota_operations
208c05c0 (d) ext3_symlink_inode_operations
208c0668 (d) ext3_fast_symlink_inode_operations
208c0710 (d) ext3_xattr_handlers
208c0740 (d) tokens
208c0a40 (d) ext3_xattr_user_handler
208c0a60 (d) ext3_xattr_trusted_handler
208c0a80 (d) ext3_xattr_acl_access_handler
208c0aa0 (d) ext3_xattr_acl_default_handler
208c0ac0 (d) ext3_xattr_security_handler
208c0b00 (d) __this_module
crash> mod -s ext3
MODULE NAME SIZE OBJECT FILE
208c0b00 ext3 200208
/lib/modules/2.6.18-1.2767.el5/kernel/fs/ext3/ext3.ko
crash> sym -m ext3 | grep "([dD])"
0 (D) __this_module
0 (D) ext3_dir_operations
0 (D) ext3_file_inode_operations
0 (d) tokens
a8 (D) ext3_dir_inode_operations
e8 (D) ext3_file_operations
150 (D) ext3_special_inode_operations
1d0 (d) ext3_ordered_aops
1f8 (d) ext3_fs_type
238 (d) ext3_sops
240 (d) ext3_writeback_aops
2b0 (d) ext3_journalled_aops
2e0 (d) ext3_export_ops
300 (D) ext3_xattr_user_handler
310 (d) ext3_qctl_operations
320 (d) ext3_xattr_handler_map
320 (D) ext3_xattr_trusted_handler
340 (D) ext3_xattr_acl_access_handler
360 (D) ext3_xattr_acl_default_handler
368 (d) ext3_quota_operations
380 (D) ext3_xattr_security_handler
3c8 (D) ext3_symlink_inode_operations
470 (D) ext3_fast_symlink_inode_operations
518 (D) ext3_xattr_handlers
crash>
I haven't been able to test it on a ppc64 or s390. (That's
why I asked for help from others on the mailing list to test
it out, but I didn't get any takers...)
In any case, as much as I like what the patch wants to do,
I can't accept it given such a serious regression. Perhaps
it could be made an experimental run-time option that could
be turned on prior to doing any "mod" commands, leaving the
current behaviour in place by default?
Thanks,
Dave
17 years, 7 months
crash version 4.0-3.15 is available
by Dave Anderson
- Introduced support for xendumps of fully-virtualized x86 kernels
taken while running on an x86 Xen host (32-bit on 32-bit host).
(anderson(a)redhat.com)
- Introduced support for xendumps of fully-virtualized x86 kernels
taken while running on an x86_64 Xen host (32-bit on 64-bit host).
(anderson(a)redhat.com)
- Introduced support for xendumps of fully-virtualized x86_64 kernels.
(anderson(a)redhat.com)
- Introduced support for xendumps of para-virtualized ia64 kernels.
It should be noted that currently the ia64 Xen kernel does not
lay down a switch_stack for the panic task, so only raw "bt -t"
backtraces can be done on the panic task. (anderson(a)redhat.com)
- Introduced support for "xm save" dumpfiles of para-virtualized ia64
kernels, which use a completely different format than that used for
x86 and x86_64. (anderson(a)redhat.com)
- Additional support for the current kexec/kdump patch for Xen:
1) Merged second round of "xencrash" patches, which allows a crash
session to be alternatively brought up against the xen-syms
binary instead of a vmlinux kernel. (oda(a)valinux.co.jp)
2) Using the xencrash feature above, the pfn_to_mfn_list_list value
of any guest domain that was running when the dom0 or hypervisor
crashed can be determined; that pfn value can in turn be used
as an argument to a new "--p2m_mfn [pfn]" crash command line
option. That will allow a crash session to be run against any
guest domain. Therefore, with a single dom0/hypervisor vmcore,
the following types of crash sessions may be initiated:
$ crash vmlinux-dom0 vmcore
$ crash xen-syms vmcore
$ crash --p2m_mfn [pfn] vmlinux-guest-#1 vmcore
$ crash --p2m_mfn [pfn] vmlinux-guest-#2 vmcore
$ ...
(anderson(a)redhat.com)
3) Fixed "help -n" debug output to properly display the contents
of the new XEN_ELFNOTE_CRASH_INFO and XEN_ELFNOTE_CRASH_REGS
ELF note types. (anderson(a)redhat.com)
- Turn off the LKCD dumpfile-access "spinner" when "crash -s" is used.
(castor.fu(a)3pardata.com)
- Update to MODULES_IN_CWD code segment so that it will work on 2.6
kernels where modules end with ".ko". This requires that kernel.c
is compiled with -DMODULES_IN_CWD. (castor.fu(a)3pardata.com)
- Support LKCD "map" files in lieu of standard System.map files.
Without this patch, crash would fail with an error message of the
sort: "crash: map.4: not a supported file format". (bwalle(a)suse.de)
- The ia64 PR_UNALIGN_NOPRINT and PR_FPEMU_NOPRINT prctl commands have
been moved earlier in time, in order to prevent "unaligned access"
messages when accessing ELF header contents. (anderson(a)redhat.com)
- The dlopen() call used by the "extensions" facility has been changed
to use the RTLD_GLOBAL flag, so that symbols from an extension object
will be visable to subsequently loaded modules. (asid(a)hp.com)
Download from: http://people.redhat.com/anderson
17 years, 7 months
[Patch] Fix dev -p command for systems with virtual devices
by Rachita Kothiyal
Hi Dave
Running 'dev -p' command on PowerPC systems with virtual devices (ie
no real PCI devices) fails with the following message:
dev: invalid kernel virtual address: 98 type: "pci bus number"
It should instead report that there are no _real_ PCI devices to list.
The following patch addresses this issue. Currently it just prints a
message letting the user know of the absence of pci devices, but it
might be a good idea to list down the virtual devices present in the
system in such cases. I am working on a patch for that too, probably
will discuss that on another thread.
Please provide your comments/suggestions.
Thanks
Rachita
On PowerPC machines configured with virtual devices(VIO) it is possible
that there are no _real_ PCI devices. Hence it is reasonable that 'dev -p'
would not list anything. This patch identifies such cases and displays a
message appropriately.
Signed-off-by: Rachita Kothiyal <rachita(a)in.ibm.com>
---
dev.c | 30 +++++++++++++++++++++++++++---
1 files changed, 27 insertions(+), 3 deletions(-)
diff -puN dev.c~fix-vio-pci-device dev.c
--- crash-4.0-3.9/dev.c~fix-vio-pci-device 2006-12-22 13:32:02.737262096 +0530
+++ crash-4.0-3.9-rachita/dev.c 2006-12-22 13:48:44.984897296 +0530
@@ -1955,13 +1955,11 @@ do_pci(void)
unsigned int class;
unsigned short device, vendor;
unsigned char busno;
- ulong *devlist, bus, devfn, tmp;
+ ulong *devlist, bus, devfn, tmp, prev, next;
char buf1[BUFSIZE];
char buf2[BUFSIZE];
char buf3[BUFSIZE];
- fprintf(fp, "%s BU:SL.FN CLASS: VENDOR-DEVICE\n",
- mkstring(buf1, VADDR_PRLEN, CENTER|LJUST, "PCI_DEV"));
BZERO(&pcilist_data, sizeof(struct list_data));
@@ -1972,11 +1970,34 @@ do_pci(void)
FAULT_ON_ERROR);
pcilist_data.end = symbol_value("pci_devices");
pcilist_data.list_head_offset = OFFSET(pci_dev_global_list);
+ readmem(symbol_value("pci_devices") + OFFSET(list_head_prev),
+ KVADDR, &prev, sizeof(void *), "list head prev",
+ FAULT_ON_ERROR);
+ /*
+ * Check if this system does not have any PCI devices.
+ * Possible on PowerPC machines with VIO configured.
+ */
+ if ((pcilist_data.start == pcilist_data.end) &&
+ (prev == pcilist_data.end)) {
+ fprintf(fp, "No PCI devices found on this system.\n");
+ return;
+ }
} else {
get_symbol_data("pci_devices", sizeof(void *),
&pcilist_data.start);
pcilist_data.member_offset = OFFSET(pci_dev_next);
+ /*
+ * Check if this system does not have any PCI devices.
+ * Possible on PowerPC machines with VIO configured.
+ */
+ readmem(pcilist_data.start + pcilist_data.member_offset,
+ KVADDR, &next, sizeof(void *), "pci dev next",
+ FAULT_ON_ERROR);
+ if (!next) {
+ fprintf(fp, "No PCI devices found on this system.\n");
+ return;
+ }
}
hq_open();
@@ -1985,6 +2006,9 @@ do_pci(void)
devcnt = retrieve_list(devlist, devcnt);
hq_close();
+ fprintf(fp, "%s BU:SL.FN CLASS: VENDOR-DEVICE\n",
+ mkstring(buf1, VADDR_PRLEN, CENTER|LJUST, "PCI_DEV"));
+
for (i = 0; i < devcnt; i++) {
/*
_
17 years, 7 months
[Patch] Fix pci devices list for dev -p command
by Rachita Kothiyal
Hi Dave
The population of pci devices list in do_pci() seems incorrect.
It wrongly assigns pci_devices.next.next as the start of the list,
instead of pci_devices.next, thereby missing one pci device in the
listing. Following patch fixes this.
Thanks
Rachita
Signed-off-by: Rachita Kothiyal <rachita(a)in.ibm.com>
---
dev.c | 4 +---
1 files changed, 1 insertion(+), 3 deletions(-)
diff -puN dev.c~fix-pci-device-list dev.c
--- crash-4.0-3.9/dev.c~fix-pci-device-list 2006-12-22 11:00:23.147609992 +0530
+++ crash-4.0-3.9-rachita/dev.c 2006-12-22 11:01:39.989928184 +0530
@@ -1967,9 +1967,7 @@ do_pci(void)
if (VALID_MEMBER(pci_dev_global_list)) {
get_symbol_data("pci_devices", sizeof(void *), &tmp);
- readmem(tmp + OFFSET(list_head_next), KVADDR,
- &pcilist_data.start, sizeof(void *), "pci devices",
- FAULT_ON_ERROR);
+ pcilist_data.start = tmp;
pcilist_data.end = symbol_value("pci_devices");
pcilist_data.list_head_offset = OFFSET(pci_dev_global_list);
_
17 years, 7 months
structure related information
by ram ba
Hi all,
I am writing a script wherein I need to obtain the values of kernel structures. I know that we can use "p <symbol_name>" command to obtain the value associated with a particular symbol.
First I need to identify whether a given symbol is a structure or a function or any variable. From whatis command we can identify the symbol definition. However if I will keep on invoking "whatis symbol" foreach symbol name,it would take a lot of time. So I wanted to know if there are any files that contains only kernel-related structures. Could any one give me a better insight in this field. I would be looking forward for your response.
Regards,
Ramya
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
17 years, 7 months
crash version 4.0-3.16 is available
by Dave Anderson
- Recognize new XC_CORE_MAGIC_HVM xendump magic number, which in turn
introduces support for xendumps of fully-virtualized ia64 kernels.
(oda(a)valinux.co.jp)
- Recognize an INVALID_MFN marker in the indexed mfn list of a xendump,
and if found, fail the read attempt on the associated pfn.
(oda(a)valinux.co.jp, anderson(a)redhat.com)
Download from: http://people.redhat.com/anderson
17 years, 7 months
crash-4.0-3.14-sym.3.patch (was: modules and data / bss initialization)
by Dave Anderson
Hi Castor,
While I have had some success with this patch on x86 and
x86_64 machines, I haven't been so fortunate with other
architectures.
On ia64 machines for example, it quite often is unable
to determine the .data segment address of a module, leaving
it as 0, so there is no improvement over the current way it works.
On the s390x, it actually causes a pretty serious regression.
For example without the patch, here are the data addresses
of the ext3 module before and after it gets loaded:
$ /usr/bin/crash -s vmlinux-2.6.18-1.2767.el5
crash> sym -m ext3 | grep "([dD])"
208bfea0 (d) ext3_dir_operations
208bff88 (d) ext3_file_operations
208c0070 (d) ext3_ordered_aops
208c00e0 (d) ext3_writeback_aops
208c0150 (d) ext3_journalled_aops
208c01c0 (d) ext3_xattr_handler_map
208c01f8 (d) ext3_file_inode_operations
208c02a0 (d) ext3_dir_inode_operations
208c0348 (d) ext3_special_inode_operations
208c03f0 (d) ext3_fs_type
208c0430 (d) ext3_sops
208c04d8 (d) ext3_export_ops
208c0508 (d) ext3_qctl_operations
208c0560 (d) ext3_quota_operations
208c05c0 (d) ext3_symlink_inode_operations
208c0668 (d) ext3_fast_symlink_inode_operations
208c0710 (d) ext3_xattr_handlers
208c0740 (d) tokens
208c0a40 (d) ext3_xattr_user_handler
208c0a60 (d) ext3_xattr_trusted_handler
208c0a80 (d) ext3_xattr_acl_access_handler
208c0aa0 (d) ext3_xattr_acl_default_handler
208c0ac0 (d) ext3_xattr_security_handler
208c0b00 (d) __this_module
crash> mod -s ext3
MODULE NAME SIZE OBJECT FILE
208c0b00 ext3 200208 /lib/modules/2.6.18-1.2767.el5/kernel/fs/ext3/ext3.ko
crash> sym -m ext3 | grep "([dD])"
208bfea0 (d) ext3_dir_operations
208bff88 (d) ext3_file_operations
208c0070 (d) ext3_ordered_aops
208c00e0 (d) ext3_writeback_aops
208c0150 (d) ext3_journalled_aops
208c01c0 (d) ext3_xattr_handler_map
208c01f8 (d) ext3_file_inode_operations
208c02a0 (d) ext3_dir_inode_operations
208c0348 (d) ext3_special_inode_operations
208c03f0 (d) ext3_fs_type
208c0430 (d) ext3_sops
208c04d8 (d) ext3_export_ops
208c0508 (d) ext3_qctl_operations
208c0560 (d) ext3_quota_operations
208c05c0 (d) ext3_symlink_inode_operations
208c0668 (d) ext3_fast_symlink_inode_operations
208c0710 (d) ext3_xattr_handlers
208c0740 (d) tokens
208c0a40 (d) ext3_xattr_user_handler
208c0a60 (d) ext3_xattr_trusted_handler
208c0a80 (d) ext3_xattr_acl_access_handler
208c0aa0 (d) ext3_xattr_acl_default_handler
208c0ac0 (d) ext3_xattr_security_handler
208c0b00 (d) __this_module
crash>
That looks fine...
However, with the patch applied, I get the following behavior:
$ crash*14/crash -s vmlinux-2.6.18-1.2767.el5
crash> sym -m ext3 | grep "([dD])"
208bfea0 (d) ext3_dir_operations
208bff88 (d) ext3_file_operations
208c0070 (d) ext3_ordered_aops
208c00e0 (d) ext3_writeback_aops
208c0150 (d) ext3_journalled_aops
208c01c0 (d) ext3_xattr_handler_map
208c01f8 (d) ext3_file_inode_operations
208c02a0 (d) ext3_dir_inode_operations
208c0348 (d) ext3_special_inode_operations
208c03f0 (d) ext3_fs_type
208c0430 (d) ext3_sops
208c04d8 (d) ext3_export_ops
208c0508 (d) ext3_qctl_operations
208c0560 (d) ext3_quota_operations
208c05c0 (d) ext3_symlink_inode_operations
208c0668 (d) ext3_fast_symlink_inode_operations
208c0710 (d) ext3_xattr_handlers
208c0740 (d) tokens
208c0a40 (d) ext3_xattr_user_handler
208c0a60 (d) ext3_xattr_trusted_handler
208c0a80 (d) ext3_xattr_acl_access_handler
208c0aa0 (d) ext3_xattr_acl_default_handler
208c0ac0 (d) ext3_xattr_security_handler
208c0b00 (d) __this_module
crash> mod -s ext3
MODULE NAME SIZE OBJECT FILE
208c0b00 ext3 200208 /lib/modules/2.6.18-1.2767.el5/kernel/fs/ext3/ext3.ko
crash> sym -m ext3 | grep "([dD])"
0 (D) __this_module
0 (D) ext3_dir_operations
0 (D) ext3_file_inode_operations
0 (d) tokens
a8 (D) ext3_dir_inode_operations
e8 (D) ext3_file_operations
150 (D) ext3_special_inode_operations
1d0 (d) ext3_ordered_aops
1f8 (d) ext3_fs_type
238 (d) ext3_sops
240 (d) ext3_writeback_aops
2b0 (d) ext3_journalled_aops
2e0 (d) ext3_export_ops
300 (D) ext3_xattr_user_handler
310 (d) ext3_qctl_operations
320 (d) ext3_xattr_handler_map
320 (D) ext3_xattr_trusted_handler
340 (D) ext3_xattr_acl_access_handler
360 (D) ext3_xattr_acl_default_handler
368 (d) ext3_quota_operations
380 (D) ext3_xattr_security_handler
3c8 (D) ext3_symlink_inode_operations
470 (D) ext3_fast_symlink_inode_operations
518 (D) ext3_xattr_handlers
crash>
I haven't been able to test it on a ppc64 or s390. (That's
why I asked for help from others on the mailing list to test
it out, but I didn't get any takers...)
In any case, as much as I like what the patch wants to do,
I can't accept it given such a serious regression. Perhaps
it could be made an experimental run-time option that could
be turned on prior to doing any "mod" commands, leaving the
current behaviour in place by default?
Thanks,
Dave
17 years, 7 months
Re: crash-4.0-3.14-sym.2.patch (was: modules and data / bss initialization)
by Dave Anderson
Hi Castor,
I was hoping to fold in your lastest crash-4.0-3.14-sym.2.patch,
but upon testing it, there is a bug that needs attention, and I'm
not sure why it occurs.
Again, it has something to do with those "__key.####" bss symbols
in the modules.
Here's a "mod -S" on an x86 machine, where it bumps into one of those
symbols in the very first module it tries to load:
crash> set debug 1
debug: 1
crash> mod -S
load_module_symbols: scsi_transport_spi /lib/modules/2.6.18-1.2747.el5xen/kernel/drivers/scsi/scsi_transport_spi.ko
ee031000 122600
186 symbols found in obj file /lib/modules/2.6.18-1.2747.el5xen/kernel/drivers/scsi/scsi_transport_spi.ko
scsi_transport_spi: update sec offset sym spi_device_configure @ ee031000 val 0 section .text
scsi_transport_spi: update sec offset sym spi_transport_exit @ ee033510 val 0 section .exit.text
scsi_transport_spi: update sec offset sym class_device_attr_period @ ee033570 val 30 section .rodata
scsi_transport_spi: update sec offset sym __ksymtab_spi_release_transport @ ee033ed8 val 0 section __ksymtab
scsi_transport_spi: update sec offset sym __kcrctab_spi_release_transport @ ee033f08 val 0 section __kcrctab
scsi_transport_spi: update sec offset sym __ksymtab_spi_populate_ppr_msg @ ee033f20 val 0 section __ksymtab_gpl
scsi_transport_spi: update sec offset sym __kcrctab_spi_populate_ppr_msg @ ee033f38 val 0 section __kcrctab_gpl
scsi_transport_spi: update sec offset sym __kstrtab_spi_release_transport @ ee033f44 val 0 section __ksymtab_strings
scsi_transport_spi: update sec offset sym ____versions @ ee034000 val 0 section __versions
scsi_transport_spi: update sec offset sym spi_transport_class @ ee036ae0 val 0 section .data
scsi_transport_spi: update sec offset sym __this_module @ ee036d80 val 0 section .gnu.linkonce.this_module
scsi_transport_spi: update sec offset sym __key.19739 @ ee037f80 val 0 section .bss
scsi_transport_spi: update sec offset sym __key.19739 @ ee037f80 val 0 section .bss
scsi_transport_spi: update sec offset sym __key.19739 @ ee037f80 val 0 section .bss
scsi_transport_spi: update sec offset sym __key.19739 @ ee037f80 val 0 section .bss
scsi_transport_spi: update sec offset sym __key.19739 @ ee037f80 val 0 section .bss
scsi_transport_spi: update sec offset sym __key.19739 @ ee037f80 val 0 section .bss
scsi_transport_spi: update sec offset sym __key.19739 @ ee037f80 val 0 section .bss
... [ spits out same message forever ] ...
i.e, continuing to loop in your new calculate_load_order_v2() function.
On an x86_64, I see the same thing, although it goes through several
other modules successfully before the infinite loop starts in the i2c_core
module:
crash> set debug 1
debug: 1
crash> mod -S
[ ... debug info removed ...]
load_module_symbols: i2c_core /lib/modules/2.6.18-1.2747.el5/kernel/drivers/i2c/i2c-core.ko ffffffff8817d000 b02600
244 symbols found in obj file /lib/modules/2.6.18-1.2747.el5/kernel/drivers/i2c/i2c-core.ko
update sec offset sym i2c_device_match @ ffffffff8817d000 val 0 section .text
update sec offset sym i2c_exit @ ffffffff8817e614 val 0 section .exit.text
update sec offset sym __ksymtab_i2c_smbus_write_i2c_block_data @ ffffffff8817e990 val 0 section __ksymtab
update sec offset sym __kcrctab_i2c_smbus_write_i2c_block_data @ ffffffff8817eb50 val 0 section __kcrctab
update sec offset sym __ksymtab_i2c_bus_type @ ffffffff8817ec30 val 0 section __ksymtab_gpl
update sec offset sym __kcrctab_i2c_bus_type @ ffffffff8817ec70 val 0 section __kcrctab_gpl
update sec offset sym __kstrtab_i2c_smbus_write_i2c_block_data @ ffffffff8817ec90 val 0 section __ksymtab_strings
update sec offset sym ____versions @ ffffffff8817efa0 val 0 section __versions
update sec offset sym i2c_bus_type @ ffffffff88182980 val 0 section .data
update sec offset sym __this_module @ ffffffff88182f80 val 0 section .gnu.linkonce.this_module
update sec offset sym __key.10825 @ ffffffff8818b180 val 0 section .bss
update sec offset sym __key.10825 @ ffffffff8818b180 val 0 section .bss
update sec offset sym __key.10825 @ ffffffff8818b180 val 0 section .bss
update sec offset sym __key.10825 @ ffffffff8818b180 val 0 section .bss
update sec offset sym __key.10825 @ ffffffff8818b180 val 0 section .bss
update sec offset sym __key.10825 @ ffffffff8818b180 val 0 section .bss
update sec offset sym __key.10825 @ ffffffff8818b180 val 0 section .bss
update sec offset sym __key.10825 @ ffffffff8818b180 val 0 section .bss
update sec offset sym __key.10825 @ ffffffff8818b180 val 0 section .bss
... [ repeat forever ] ...
First I had thought that it would start spinning upon encountering the first
module with one of those __key.##### symbols -- which was true in
the case of the x86 machine.
However, in the above x86_64 machine, several other modules with those
__key.#### bss symbols types did get loaded OK before getting hung up
loading i2c_core module.
For example, if I do the loads individually on the x86_64, the jbd module
loads OK, but the i2c_core hangs:
crash> sym -m jbd | grep __key
ffffffff8804b0b0 (b) __key.16794
ffffffff8804b0b0 (b) __key.16795
crash> mod -s jbd
MODULE NAME SIZE OBJECT FILE
ffffffff88042e80 jbd 98609 /lib/modules/2.6.18-1.2747.el5/kernel/fs/jbd/jbd.ko
crash> sym -m i2c_core | grep __key
ffffffff8818b180 (b) __key.10825
ffffffff8818b180 (b) __key.10826
crash> mod -s i2c_core
< hang >
Can you see if you can reproduce, and hopefully fix this?
Thanks,
Dave
17 years, 7 months
