----- Original Message ----- > On Sun, Mar 24, 2013 at 04:58:33PM +0800, Lei Wen wrote: > > Mika, > > > > On Fri, Mar 22, 2013 at 9:03 PM, Mika Westerberg > > <mika.westerberg@xxxxxx> wrote: > > > On Thu, Mar 21, 2013 at 03:02:54PM -0400, Dave Anderson wrote: > > >> If for some reason you can't get them, I can make them available > > >> to you. > > >> And Lei Wen can also give you a sample dumpfile from his > > >> environment. > > > > > > Got them from Luc. > > > > > >> > Are you able to access module symbols on ARM dump (the one > > >> > that Luc provided)? > > >> > Or is it failing completely? > > >> > > >> I *think* so... > > >> > > >> This module text disassembly looks right: > > >> > > >> crash> dis usbnet_suspend > > >> 0xbf000ae8 <usbnet_suspend>: push {r3, r4, r5, lr} > > >> 0xbf000aec <usbnet_suspend+4>: add r0, r0, #32 > > >> 0xbf000af0 <usbnet_suspend+8>: mov r5, r1 > > >> 0xbf000af4 <usbnet_suspend+12>: bl 0xc01b8264 > > >> <dev_get_drvdata> > > >> 0xbf000af8 <usbnet_suspend+16>: ldrb r3, [r0, #36] ; 0x24 > > >> 0xbf000afc <usbnet_suspend+20>: mov r4, r0 > > >> 0xbf000b00 <usbnet_suspend+24>: add r2, r3, #1 > > >> 0xbf000b04 <usbnet_suspend+28>: cmp r3, #0 > > >> 0xbf000b08 <usbnet_suspend+32>: strb r2, [r0, #36] ; 0x24 > > >> 0xbf000b0c <usbnet_suspend+36>: bne 0xbf000bdc > > >> <usbnet_suspend+244> > > >> 0xbf000b10 <usbnet_suspend+40>: mrs r3, CPSR > > >> 0xbf000b14 <usbnet_suspend+44>: orr r3, r3, #128 ; 0x80 > > >> 0xbf000b18 <usbnet_suspend+48>: msr CPSR_c, r3 > > >> 0xbf000b1c <usbnet_suspend+52>: mov r0, #1 > > >> 0xbf000b20 <usbnet_suspend+56>: bl 0xc0015f40 > > >> <add_preempt_count> > > >> 0xbf000b24 <usbnet_suspend+60>: ldr r3, [r4, #200] ; 0xc8 > > >> 0xbf000b28 <usbnet_suspend+64>: cmp r3, #0 > > >> 0xbf000b2c <usbnet_suspend+68>: beq 0xbf000b70 > > >> <usbnet_suspend+136> > > >> 0xbf000b30 <usbnet_suspend+72>: tst r5, #1024 ; 0x400 > > >> 0xbf000b34 <usbnet_suspend+76>: beq 0xbf000b70 > > >> <usbnet_suspend+136> > > >> 0xbf000b38 <usbnet_suspend+80>: mrs r3, CPSR > > >> ... > > >> > > >> This (r) data looks OK: > > >> > > >> crash> p smsc95xx_netdev_ops > > >> smsc95xx_netdev_ops = $8 = { > > >> ndo_init = 0, > > >> ndo_uninit = 0, > > >> ndo_open = 0xbf000514 <usbnet_open>, > > >> ndo_stop = 0xbf000bec <usbnet_stop>, > > >> ndo_start_xmit = 0xbf001a60 <usbnet_start_xmit>, > > >> ndo_select_queue = 0, > > >> ndo_change_rx_flags = 0, > > >> ndo_set_rx_mode = 0, > > >> ndo_set_multicast_list = 0xbf008abc <smsc95xx_set_multicast>, > > >> ndo_set_mac_address = 0xc025d854 <eth_mac_addr>, > > >> ndo_validate_addr = 0xc025d6f8 <eth_validate_addr>, > > >> ndo_do_ioctl = 0xbf00926c <smsc95xx_ioctl>, > > >> ndo_set_config = 0, > > >> ndo_change_mtu = 0xbf000de0 <usbnet_change_mtu>, > > >> ndo_neigh_setup = 0, > > >> ndo_tx_timeout = 0xbf000d4c <usbnet_tx_timeout>, > > >> ndo_get_stats64 = 0, > > >> ndo_get_stats = 0, > > >> ndo_vlan_rx_add_vid = 0, > > >> ndo_vlan_rx_kill_vid = 0, > > >> ndo_set_vf_mac = 0, > > >> ndo_set_vf_vlan = 0, > > >> ndo_set_vf_tx_rate = 0, > > >> ndo_get_vf_config = 0, > > >> ndo_set_vf_port = 0, > > >> ndo_get_vf_port = 0, > > >> ndo_setup_tc = 0, > > >> ndo_add_slave = 0, > > >> ndo_del_slave = 0, > > >> ndo_fix_features = 0, > > >> crash> > > > > > > I'm able to see the same. > > > > > > Setting suitable debug level reveals: > > > > > > bf00f040 (bf00f000): scsi_wait_scan syms: 0 gplsyms: 0 > > > ksyms: 1 > > > bf00a1f8 (bf008000): smsc95xx syms: 0 gplsyms: 0 ksyms: > > > 60 > > > bf002a40 (bf000000): usbnet syms: 0 gplsyms: 24 ksyms: 65 > > > > > > The ksyms comes from KALLSYMS and by default it only includes > > > text and > > > inittext symbols. This explains why Lei is not able to see data > > > etc. symbols > > > when he runs 'sym -m <module>'. > > > > Yep, that is my case. For data symbol would only be included in > > core section > > if CONFIG_KALLSYMS_ALL option is defined, so crash fail to extract > > the data symbol since it fail to see the data section is included > > in > > the dump image. > > > > But what I am confused is that since mod -S would reload all module > > image, > > which already include all symbols. So why we should confine us to > > only > > extract those symbol in the core section defined by the dump image? > > Well, crash (or the embedded GDB) is able to extract data symbols as > well even > though you can't see them by running 'sym' command. > > > I mean even with CONFIG_KALLSYMS be defined, I think it maybe > > doable to > > extract all data symbol. What are your guys' opinion here? :) > > We can always review a patch that adds such support ;-) Right, and again, when I modified store_load_module_symbols_v2() as indicated here: https://www.redhat.com/archives/crash-utility/2013-March/msg00130.html I *do* see some of the (d) symbols in the "sym" display. There's something odd about the ARM module.ko files such that lm->mod_sections is not quite the right count. There must be something w/respect to section name strings or something that is not seen with the other architectures. Dave -- Crash-utility mailing list Crash-utility@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/crash-utility