----- Original Message -----
These are the same lines in my case.
<readmem: c0d2af6c, KVADDR, "crash_notes", 4, (ROE), 85ba84c>
<read_kdump: addr: c0d2af6c paddr: 80f2af6c cnt: 4>
<readmem: f9fe0000, KVADDR, "note_buf_t", 560, (ROE), 85bac40> <---
!!
<readmem: c0004000, KVADDR, "pgd page", 16384, (FOE), 914e8d0>
I have never seen this problem before, so the behavior you see is
exactly what I have seen before. However with a fairly new kernel I
did not get the correct crash_notes. The investigation lead to the
patch for the problem described in my previous mail.
I have not investigated if there is any patch in newer kernels that
changes this behavior and in that case where it comes from (it could
be a patch by us). However as the algorithm for reading crash_notes
is wrong, as it depends on a variable that is not yet initialized, I
think it should be corrected anyhow. I have tested my patch with
both newer and older kernels and it works as intended.
OK, good. And so apparently the per-cpu region has been moved up
into vmalloc space. I'll queue the change into crash-6.0.9.
For curiosity's sake, can you show me the per-cpu symbol list? In
my sample ARM kernel, it's located in the unity-mapped region just
below the .text section, and can be seen like this:
crash> sym -l
... [ cut ] ...
c004e000 (d) .data..percpu
c004e000 (D) __per_cpu_load
c004e000 (D) __per_cpu_start
c004e000 (D) cpu_data
c004e040 (d) percpu_clockevent
c004e098 (D) current_kprobe
c004e09c (D) kprobe_ctlblk
c004e130 (d) bp_on_reg
c004e170 (d) wp_on_reg
c004e1b0 (D) mmu_gathers
c004e1c0 (D) current_mm
c004e1e0 (D) kstat
... [ cut ] ...
c004f0b4 (d) xmit_recursion
c004f0b8 (d) rt_cache_stat
c004f100 (d) runqueues
c004f620 (d) gcwq_nr_running
c004f640 (d) cfd_data
c004f660 (d) call_single_queue
c004f6a0 (d) csd_data
c004f6c0 (D) softnet_data
c004f7a0 (D) __per_cpu_end
c0050000 (t) .text
...
Your newer kernel must move it up to ~fxxxxxxx?
Thanks,
Dave