Received-SPF: pass (google.com: domain of linux-kernel+bounces-176945-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) client-ip=139.178.88.99;
Precedence: bulk
MIME-Version: 1.0
From: Muni Sekhar <munisekharrms@gmail.com>
Date: Sun, 12 May 2024 22:40:29 +0530
Message-ID: <CAHhAz+hcVRU8=SkkoHGRDN5zRvB2HY1-1Y2NQmNwR=07ObSFrQ@mail.gmail.com>
Subject: Inquiry Regarding Handling of Kernel Crashes
To: kernelnewbies <kernelnewbies@kernelnewbies.org>, LKML <linux-kernel@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"

Dear Linux Kernel Community,

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?

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?

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?

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.


-- 
Thanks,
Sekhar