Thanks for the reply.
However, I believe that's an expected behavior when simulating a crash.
See the following doc, which states "'c' - Will perform a system crash by a
NULL pointer dereference. A crashdump will be taken if configured."
https://www.kernel.org/doc/Documentation/sysrq.txt
*Andre
Hello
as you see in the kernel trace, maybe it's kernel BUG, i don't know if
there is an open bug for this, but it can be useful if you try to do the
same thing with an other kernel.
2013/7/29 Andrew Walsh
> Here is the output once I trigger the crash:
>
>
>
> [3518.067263] SysRq : Trigger a c
Here is the output once I trigger the crash:
[3518.067263] SysRq : Trigger a crash
[3518.070526] BUG: unable to handle kernel NULL pointer dereference at
(null)
[3518.071338] IP: [] sysrq_handle_crash+0xd/0x16
[3518.072163] PGD 7c781067 PUD 7c780067 PMD 0
[3518.072973] Oops: 0002 [#1] SMP
[
Can you show us the screen when crash happen? after you give echo c >
/proc/sysrq-trigger
2013/7/29 Andrew Walsh
> Yes, it appears that it was loaded as expected:
>
> # grep -i crash /proc/iomem
>
> 3300-36ff : Crash kernel
>
>
>
> Thanks for the response.
>
> *Andrew Walsh*
>
--
Yes, it appears that it was loaded as expected:
# grep -i crash /proc/iomem
3300-36ff : Crash kernel
Thanks for the response.
*Andrew Walsh*
Hello
After you reboot and configure your kdump, before you do the test crash
dump, check if your crash kernel was loaded corretly with grep -i crash
/proc/iomem
2013/7/29 Andrew Walsh
> Hi all,
>
>
>
> I’ve got an issue trying to configure kdump on my debian systems, and I
> was hoping some
6 matches
Mail list logo
