[Crash-utility] Re: crash-4.0-3.14-sym.2.patch (was: modules and data / bss initialization)

Castor Fu castor.fu at 3pardata.com
Mon Dec 18 06:58:07 UTC 2006 

Hi Dave!

I reproduced the problem on an FC6 system here.  It looks like 
the symbol which is causing the problem is only
nominally in the BSS segment, i.e. the symbol
is at bss_start+bss_size, even though it claims
to be in the bss segment.

I'm attaching a patch where I end up skipping
over symbols which don't fit in.  I had somehow
left out one line when writing the original code 
which would have fixed this.

Also there's a small fix to my changes to the MODULES_IN_CWD
code, because I was breaking finding some modules on 2.4 kernels.

Thanks for your testing and help!

    -castor






-----Original Message-----
From: crash-utility-bounces at redhat.com on behalf of Dave Anderson
Sent: Fri 12/15/2006 8:46 AM
To: Castor Fu
Cc: crash-utility at redhat.com
Subject: [Crash-utility] Re: crash-4.0-3.14-sym.2.patch (was: modules and data / bss initialization)
 

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


--
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/20061217/66d522c2/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: crash-4.0-3.14-sym.3.patch
Type: application/octet-stream
Size: 9961 bytes
Desc: crash-4.0-3.14-sym.3.patch
URL: <http://listman.redhat.com/archives/crash-utility/attachments/20061217/66d522c2/attachment.obj>

More information about the Crash-utility mailing list