Comment # 63 on bug 1188896 from LTC BugProxy

------- Comment From geraldsc@de.ibm.com 2022-02-17 12:45 EDT-------
Thanks, that looks (almost) good. I can open the dump with the vmlinux in
crash, and see the kernel messages. As expected, the log buffer is completely
filled with rcu_sched messages, starting at timestamp [33838.823685], and
previous messages are lost. This should not be a problem when we have a dump
with panic_on_taint setting, as that would immediately stop the system at the
interesting part, and not have all the follow-on messages.

However, "bt -a" does not work in crash with this dump, it shows all registers
0, and error "bt: invalid kernel virtual address: 20003c0600000d8  type:
"readmem_ul"".

This looks a bit like a (normal) stand-alone dump w/o "CPU store status", but
current dump solutions should not require that any more. Of course, the
"dump-guest-memory" approach does not sound like the normal dump solutions, at
least I am not at all familiar with it, and find also no mention of that in our
dump tools documentation. A normal "CPU store status" like in LPAR or z/VM is
probably not possible in your case.

Do you know if kdump would work in your system, i.e. when you would get a
normal panic with panic_on_taint setting, then (on a normal system) kdump would
trigger a dump? If not, we might wait and see if the dump with
"dump-guest-memory" would maybe produce better results in that case, i.e. when
the system gets dumped after it ended in a panic, instead of dumping it from a
running state.

At least we now have a working process to submit dumps plus matching vmlinux,
which is good.