http://bugzilla.opensuse.org/show_bug.cgi?id=1200919 http://bugzilla.opensuse.org/show_bug.cgi?id=1200919#c18 --- Comment #18 from Hillwood Yang <hillwoodroc@gmail.com> --- (In reply to Chester Lin from comment #17)

(In reply to Matthias Brugger from comment #16)

...

(In reply to Hillwood Yang from comment #11)

...

(In reply to Takashi Iwai from comment #10)

...

Try to trigger the crash via "echo c > /proc/sysrq-trigger", and confirm that kdump is working (you get the crash dump). If it doesn't work, it means that kdump setup is likely insufficient. Try to increase the reserve memory size, for example.

Surprise! I confirm I enable kdump in Yast2, and set crashkernel as 1024M. But kdump still does not work, /var/crash is allways empty.

I think you have to define an offset for the crashkernel to make that work. Chester do you remember?

In general, users don't need a specific offset to tell the arm64 kernel where the crashkernel should be located because the arm64/mm init code should search every available memblock until a proper and free memory area can be reserved [See init.c: reserve_crashkernel()]. Regarding the kdump issue, I wonder if Hillwood could help to collect the following logs with kdump configs enabled, which can help us to check whether the kdump service is successfully activated or not:

* Note1: Please remove the 'quiet' option from the kernel command-line parameters to get more information during kernel boot. * Note2: Please ensure that your system is rebooted after kdump is enabled.

# dmesg # journalctl -u kdump --no-pager

Besides, I noticed that your system has an SPCR table in ACPI, which means you could try collecting kernel logs in the early stages through the serial/UART port by simply adding the following option in the kernel command line:

earlycon=pl011,mmio32,0x94080000

Sorry, It really works on "echo c > /proc/sysrq-trigger". I should wait much time. But it does not work on this issue. -- You are receiving this mail because: You are the assignee for the bug.