Comment # 49 on bug 1188896 from LTC BugProxy

------- Comment From geraldsc@de.ibm.com 2022-02-08 14:08 EDT-------
(In reply to comment #46)
> no, the link is purely internal and the dump was only created using
> gdb and the dump-guest-memory script in the qemu repo on a hanging vm that
> was stuck for longer.
>
> will look at the details later for upload if you are interested in that one

In the best case, such a dump could at least show the kernel messages, while
the rest of it would be useless. However, we previously already had such a dump
from a long stuck system, where the kernel log buffer was completely filled
with repeating rcu_sched or similar errors, so that it still could not reveal
the messages at the time when it all started. It still would be better than
nothing, and at least serve as an exercise how to collect and submit a dump :-)

The best chance would be the "panic_on_taint=5" kernel parameter approach,
although I cannot 100% guarantee that it will work as expected. It was
suggested by Fabian in an earlier comment here:

"The "bad page state" warning causes a taint, so panic_on_taint=5 should help
there. Needs an OBS admin to add that option and get a dump though, or
alternatively someone who can reproduce it (somewhat reliably) with
osc build --vm-type=kvm."

I frankly wasn't aware of that feature myself, but a quick check in the kernel
source code seems to confirm that this kernel parameter should trigger a panic
on a "bad page state" event (and no other possible kernel taints), at least
since kernel 5.8. After that, it should be possible to collect a dump in the
same way that you did already.