Try using strace and see if all of the different crashes have the same or similar looking call stack.
Here's a link on how to use it in case you didn't know already: http://stackoverflow.com/questions/174942/how-to-use-strace
Here's a link on how to use it in case you didn't know already: http://stackoverflow.com/questions/174942/how-to-use-strace
From: manty kuma
Sent: 7/7/2013 8:06 PM
To: Valdis Kletnieks
Cc: kernelnewbies@xxxxxxxxxxxxxxxxx
Subject: Re: Debugging techniques inside kernel
Hi Valdis,
Thanks for the info. I have serial logs (using minicom). This is not helping me much as randomly memory is getting crashed and everytime it changes. Even the logs before the crash are varying everytime. On Mon, Jul 8, 2013 at 11:49 AM, <Valdis.Kletnieks@xxxxxx> wrote:
On Mon, 08 Jul 2013 11:22:16 +0900, manty kuma said:
> For ex : *CONFIG_SLUB_DEBUG_ON, *CONFIG_DMA_API_DEBUG
> I am just told to use these configs and check. Not sure how to use themMost _DEBUG config options are set-and-forget - you turn them on and
> effectively. Please share if you are aware of these kind of configs and how
> to use them. To have them at one place it would be useful for debugging
> beginners like me.
there's no further configuration needed. They enable additional code
that does additional sanity checking and if it finds a problem, it issues
a printk() or a stack dump or similar which shows up in dmesg.
If you're chasing memory corruption, it may be useful to use netconsole
or a serial console to send out all the printk() output in real time, as
often an error will be detected but the system will panic()/crash/hang
in a way that your local syslog daemon is unable to write the message to
disk. (I'm told that on newer UEFI based systems, you can use pstore in
a similar fashion, but have not tried it myself yet).
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@xxxxxxxxxxxxxxxxx http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
