https://bugzilla.suse.com/show_bug.cgi?id=1188896 https://bugzilla.suse.com/show_bug.cgi?id=1188896#c63 --- Comment #63 from LTC BugProxy <bugproxy@us.ibm.com> --- ------- 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. -- You are receiving this mail because: You are the assignee for the bug.