From: "Dr. David Alan Gilbert" <linux@treblig.org>
To: Muni Sekhar <munisekharrms@gmail.com>
Cc: kernelnewbies <kernelnewbies@kernelnewbies.org>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: Inquiry Regarding Handling of Kernel Crashes
Date: Sun, 12 May 2024 20:50:24 +0000 [thread overview]
Message-ID: <ZkErkG77vLkcVaUZ@gallifrey> (raw)
In-Reply-To: <CAHhAz+hcVRU8=SkkoHGRDN5zRvB2HY1-1Y2NQmNwR=07ObSFrQ@mail.gmail.com>
* Muni Sekhar (munisekharrms@gmail.com) wrote:
> Dear Linux Kernel Community,
Hi,
> I hope this email finds you well. I am currently engaged in testing
> device drivers in Linux kernel mode, and I have encountered various
> types of kernel crashes during my testing process.
>
> Among these, some examples of kernel crashes include OOPS, lockups and others.
>
> I have a few questions regarding the handling of kernel crashes during testing:
>
> When encountering a kernel crash during testing, is it advisable to
> continue testing without rebooting the system? Or is it preferable to
> reboot the system after each kernel crash and then resume testing?
Rebooting is best.
> Can the first kernel crash, whether it is an OOPS, or any other type
> crash, potentially lead to subsequent crashes of the same or different
> types? If so, should debugging efforts focus only on the first kernel
> crash, or should all subsequent crashes also be considered and
> addressed?
Yes - not all failures do that, but some will cause follow on crashes;
looking at the first crash normally gives the most reliable idea
of what went wrong. But keep all the logs, anything might help you figure
it out.
> In the event that the system needs to be rebooted after a kernel
> crash, how can user space test utilities be informed that a kernel
> crash has occurred? Additionally, how can the system be configured to
> automatically reboot in the event of a kernel crash?
See Documentation/admin-guide/kernel-parameters.txt there are
quite a few useful ones, in particular:
oops=panic will cause a panic after an oops
which when you combine it with
panic=30
means an oops will then cause a panic which causes a reboot.
You could also consider using a 'crash kernel' - on a panic
that lands in a fresh kernel that just saves a memory snapshot
that you can then try and debug.
Turning on a watchdog as well is good; some kernel bugs just hang
rather than giving a nice oops.
> I would greatly appreciate any insights or best practices you can
> share regarding the handling of kernel crashes during testing. Your
> expertise and guidance on this matter would be invaluable to my
> testing efforts.
>
> Thank you very much for your time and assistance. I look forward to
> your response.
Good luck!
Dave
>
>
> --
> Thanks,
> Sekhar
>
--
-----Open up your eyes, open up your mind, open up your code -------
/ Dr. David Alan Gilbert | Running GNU/Linux | Happy \
\ dave @ treblig.org | | In Hex /
\ _________________________|_____ http://www.treblig.org |_______/
prev parent reply other threads:[~2024-05-12 20:50 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-12 17:10 Inquiry Regarding Handling of Kernel Crashes Muni Sekhar
2024-05-12 17:10 ` Muni Sekhar
2024-05-12 20:50 ` Dr. David Alan Gilbert [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ZkErkG77vLkcVaUZ@gallifrey \
--to=linux@treblig.org \
--cc=kernelnewbies@kernelnewbies.org \
--cc=linux-kernel@vger.kernel.org \
--cc=munisekharrms@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.