[Crash-utility] crash version 4.0-3.18 is available

Fri Feb 2 18:24:42 UTC 2007

Xavier:

I suspect that if rpc_execute is duplicated, there are other duplicated
symbols
and so we matched some other symbol, got another offset, and at that 
point we're headed down the wrong path.  It hadn't occurred to me that
there could be conflicts, but in retrospect it makes sense.

Not quite sure how to resolve this.  I'd hate to trust that we could
reliably
duplicate Linux'es module loading algorithm.

________________________________

From: crash-utility-bounces at redhat.com
[mailto:crash-utility-bounces at redhat.com] On Behalf Of xb
Sent: Friday, February 02, 2007 1:32 AM
To: anderson at redhat.com
Cc: Discussion list for crash utility usage, maintenance and development
Subject: Re: [Crash-utility] crash version 4.0-3.18 is available

Hi Dave and all

I still have some problems with module symbols on ia64. (I built crash
4.0-3.17 + 4.0-3.17-to-4.0-3.18.patch).

It seems that when I run the commans:

mod -s <module name> 

the text symbol addresses are not the ones provided by kallsyms.
Any idea ?
Thanks in advance.
Xavier

Traces
------------------------------------------------------------------------
-------------------------------------------------------------
# ./crash /boot/vmlinux-2.6.18-B64k.1.7

crash 4.0-3.17
Copyright (C) 2002, 2003, 2004, 2005, 2006, 2007  Red Hat, Inc.
...
GNU gdb 6.1
...
This GDB was configured as "ia64-unknown-linux-gnu"...

      KERNEL: /boot/vmlinux-2.6.18-B64k.1.7
    DUMPFILE: /dev/mem
        CPUS: 8
        DATE: Fri Feb  2 10:25:27 2007
      UPTIME: 13 days, 16:26:51
LOAD AVERAGE: 0.75, 0.66, 0.58
       TASKS: 286
    NODENAME: xxx
     RELEASE: 2.6.18-B64k.1.7
     VERSION: #1 SMP Fri Jan 5 14:05:06 CET 2007
     MACHINE: ia64  (1599 Mhz)
      MEMORY: 63.9 GB
         PID: 17276
     COMMAND: "crash"
        TASK: e000002025600000  [THREAD_INFO: e000002025600f40]
         CPU: 7
       STATE: TASK_RUNNING (ACTIVE)

crash> sym -l |grep rpc_execute
a000000207d34a80 (t) __rpc_execute
a000000207d351e0 (t) rpc_execute
a000000207d5a590 (?) rpc_execute
a000000207d5bde0 (r) __ksymtab_rpc_execute
a000000207d5c6d0 (r) __kstrtab_rpc_execute
a000000207d5cab0 (r) __kcrctab_rpc_execute
crash> disas rpc_execute
No symbol "rpc_execute" in current context.
crash> mod -s sunrpc
     MODULE       NAME                  SIZE  OBJECT FILE
a000000207d82280  sunrpc              414976
/lib/modules/2.6.18-B64k.1.7/kernel/net/sunrpc/sunrpc.ko
crash> disas rpc_execute
Dump of assembler code for function rpc_execute:
0xa000000207d5ac10 <rpc_execute+0>:     [MII]       break.m 0x0
0xa000000207d5ac11 <rpc_execute+1>:                 break.i 0x0
0xa000000207d5ac12 <rpc_execute+2>:                 break.i 0x0
...
End of assembler dump.
crash> disas 0xa000000207d351e0 0xa000000207d35200
# This one is OK
Dump of assembler code from 0xa000000207d351e0 to 0xa000000207d35200:
0xa000000207d351e0:     [MMI]       nop.m 0x0;;
0xa000000207d351e1:                 alloc r34=ar.pfs,5,4,0
0xa000000207d351e2:                 mov r33=b0
0xa000000207d351f0:     [MMI]       nop.m 0x0
0xa000000207d351f1:                 mov r35=r1
0xa000000207d351f2:                 adds r17=208,r32;;
End of assembler dump.
crash>                     

Dave Anderson wrote: 

	- Enhancement to the "mod" command to expand the number of
section 
	  arguments to the internal "add-symbol-file" command issued to
gdb to 
	  load the debug data for module objects.  On most
architectures,  this 
	  allows the usage of the command construct "p
[module-symbol-name]" to 
	  print out the module data structure in the same way that is
done for 
	  kernel proper data structure names.  (castor.fu at 3pardata.com) 

	- Two enhancements to significantly speed up the initialization
of 
	  crash sessions when running against multi-gigabyte xen kernels
or 
	  xendumps.  The cache of mfn-to-phys_to_machine_mapping page
has been 
	  changed from a single-mfn-to-phys_to_machine_mapping page
format to 
	  storing a contiguous-range-of-mfns-to-phys_to_machine_mapping
format. 
	  This benefit is primarily seen during the "gathering module
symbol 
	  data" phase.  The second change simply increases the size of
the 
	  pfn-to-xendump-page-offset cache.  (anderson at redhat.com) 

	- Fix for a segmentation violation during the "gathering task
table 
	  data" phase of initialization if the thread_info structure of
the 
	  runqueue-advertised active task has been freed.  This has only
ever 
	  been seen in a xendump created by "xm dump-core -L
[guest-domain]". 
	  (anderson at redhat.com) 

	- Cosmetic fix to prepend newlines to messages that happen to be

	  generated during any of the "please wait" segments of
initialization. 
	  (anderson at redhat.com) 

	- Addressed several compiler warnings when using
-D_FORTIFY_SOURCE=2. 
	  Some are in gdb code that is never exercised, others were
legitimate 
	  but would require impossible code paths, but one of them could

	  result in runaway "help -t" output if the kernel was built
without 
	  IKCONFIG.  (bwalle at suse.de) 

	- Fix for the s390x "bt -f" command option, which was displaying
the 
	  stack as a sequence of 32-bit words which were dumped
"backwards", 
	  i.e., at the wrong offset.  (krader at us.ibm.com) 

	- http://people.redhat.com/anderson/4.0-3.17-to-4.0-3.18.patch 

	Download from: http://people.redhat.com/anderson 

________________________________

	--
	Crash-utility mailing list
	Crash-utility at redhat.com
	https://www.redhat.com/mailman/listinfo/crash-utility

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/crash-utility/attachments/20070202/f9d6f1a9/attachment.htm>