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(a)redhat.com 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.
Dave