On Aug 3, 2013 3:02 AM, "neha naik" <[email protected]> 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, <[email protected]> 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 > [email protected] > http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies >
_______________________________________________ Kernelnewbies mailing list [email protected] http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
