On Aug 3, 2013 3:02 AM, "neha naik" <nehanaik27@gmail.com> wrote:
Hi All, I looked into my issue and i had only one cpu on that machine and i was
getting messages like process # waiting for # secs.
My theory is that this process was of doing some kind of busy looping on that cpu so that the operating system could not even generate a dump. The moment i increased the number of cpus i got the dump. I am just posting this How did you do that?How can you limit the number of cpus?I wonder if there is some sysfs control for that? because someone else may find it useful.
Regards, Neha
On Thu, May 30, 2013 at 11:44 AM, <Valdis.Kletnieks@vt.edu> wrote:
On Thu, 30 May 2013 11:31:49 -0600, neha naik said:
I have loaded the linux crashdump on ubuntu machine. I can manually generate the crashdump by the 'echo c > /proc/sysrq-trigger'. However, i am having a panic in a module i have written, which is not generating a core dump. I simply see the stack in the console and it
kind of
hangs there. I have to manually power it off and power it on ... Can someone explain why this happens? Is it because the kernel has gone into such a state that it cannot even follow the procedure for crash dump.
Most likely, your module isn't in fact panic'ing, but oops'ing. There's a number of kernel variables that control whether to panic.
ls -l /proc/sys/kernel/*panic*
and for example 'echo 1 > /proc/sys/kernel/panic_on_oops' will cause a panic if something oops'es.
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies