Hello all,

I have a arm device, an overo gumstix air board with 2.4 Linux kernel in it. I have an application running on it which will talk to two custom char drivers that I've written. The application has a TCP socket which talks to an outside server. I frequently noticed that the wifi connectivity of the machine turns off automatically. First I thought that this is something with the internet connectivity and I wrote a small daemon program to tackle that. But I got to know then it's not the internet connection, but the whole system is stuck at that point. So I enabled the watchdog timer of the board. Then I started to notice that my machine keeps on restarting during the run time of my program. Can this be something with wrong practice in writing the drivers? Or has anyone seen this kind of behaviors? Or is there any way I can narrow down what caused the system stuck condition?

I'm starting to think that a malfunction of an user level program can not let the machine reboot. Can this be some issue with the malpractices in driver writing. If so, is there are any way I can narrow down this issue. FYI: this scenario is very random, happens once a time. But my application is very time critical. So I must stop any malpractices.

Thanks all

Where are you getting a 2.4 kernel for the overo? I've never seen anything that old for them. The current OE omap3-console-image uses a 3.0.0 kernel, and even images dating back years are still in the 2.6.3? range. I think the first step should be to update to a newer build with better stability and better support for the hardware.

I'm really sorry, my kernel is not 2.4 but 2.6.34
I'm really sorry for the mistake. Any suggestions?