----- "Dave Anderson" <anderson@xxxxxxxxxx> wrote: > This is a post from a non-member that I approved (as list moderator), > but for some reason it didn't get sent out: > > caiqian@xxxxxxxxxx wrote: > > Hi, > > > > I would like to check with you about one thing happened on IA64 > only. > > > > crash> bt -r > > > > ... > > a0000001007ec100: 0000000000000000 00000000000001f4 > > a0000001007ec110: 0000000000000000 0000000000000000 > > a0000001007ec120: 0000000000000000 0000000000000000 > > a0000001007ec130: 0000000000000000 v+10731618616 > > a0000001007ec140: v+4808933688 0000000000000000 > > a0000001007ec150: v+4350567296 0000000000000000 > > a0000001007ec160: 0000000000000000 0000000000000000 > > a0000001007ec170: 0000000000000000 0000000000000000 > > a0000001007ec180: 0000000000000000 0000000000000000 > > a0000001007ec190: init_task v+10731618728 > > a0000001007ec1a0: v+10731618728 init_task+424 > > a0000001007ec1b0: init_task+424 init_task > > ... > > > > What are those "v+XXXXXXXXXX"? > > > > Thanks, > > Cai Qian > > > Yean, you'll also see the same thing if you do a "rd -s <address>", > like this example: > > crash> bt -r > ... > e0000100ff0d1640: v+1103759521536 v+1103765979464 > e0000100ff0d1650: v+1103758983168 scsi_softirq_done+656 > e0000100ff0d1660: 000000000000030a scsi_execute_async+6928 > e0000100ff0d1670: v+1103759521536 000000000251e042 > ... > crash> rd -s e0000100ff0d1640 8 > e0000100ff0d1640: v+1103759521536 v+1103765979464 > e0000100ff0d1650: v+1103758983168 scsi_softirq_done+656 > e0000100ff0d1660: 000000000000030a scsi_execute_async+6928 > e0000100ff0d1670: v+1103759521536 000000000251e042 > crash> > > The "v+offset" values are translations of unity-mapped (ia64 region 7) > kernel virtual addresses: > > crash> rd e0000100ff0d1640 8 > e0000100ff0d1640: e0000100fd31b700 e0000100fd944148 > ..1.....HA...... > e0000100ff0d1650: e0000100fd298000 a000000203f9bb90 > ..)............. > e0000100ff0d1660: 000000000000030a a000000203fbc3d0 > ................ > e0000100ff0d1670: e0000100fd31b700 000000000251e042 > ..1.....B.Q..... > crash> > > which are seen as offsets from the closest "symbol", which is "v": > > crash> sym -l > ... > a000000100dc1e00 (b) xfrm_state_gc_work > a000000100dc1e60 (b) __key.33744 > a000000100dc1e68 (B) unix_socket_table > a000000100dc2670 (A) _end > e000000000000000 (A) v > ffffffffffff0000 (D) __per_cpu_start > ffffffffffff0000 (d) per_cpu__cpu_idle_state > ffffffffffff0008 (D) per_cpu__pfm_syst_info > ffffffffffff0010 (D) per_cpu__pmu_owner > ... > > This has to do with older ia64 kernels which compiled the kernel text > and data segments into region 7, based at e000000000000000. Newer > ia64 kernels map the kernel text and static data segments into > ia64 region 5, based at a000000000000000, although all other > physical memory is still unity-mapped at ia64 region 7. > > Although it could probably be done with an ia64-specific hack, > I'm somewhat hesitant to change this behavior. I've overcome my hesitation, and will address this in the next release. The problem is that the ia64 contains legitimate kernel symbols beyond "_end", namely the "v" and the per_cpu pseudo-symbols. As it turns out, as long is the change is restricted to the "bt -r" and "rd -[sS]" commands, it's not a particularly ugly hack. And if in the future another architecture ends up containing base kernel symbols beyond "_end", the patch can be adapted for use in those cases as well. Dave -- Crash-utility mailing list Crash-utility@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/crash-utility
