Linux - GeneralThis Linux forum is for general Linux questions and discussion.
If it is Linux Related and doesn't seem to fit in any other forum then this is the place.
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
A "kernel oops" is a non-fatal error within the kernel. (A "kernel panic" is, of course, fatal.) The problem occurred in kernel-space, not user-space, so it strongly implies that there is a problem in some kernel module. Some kind of physical I/O error condition, in this case, also cannot be excluded.
A study of the kernel map for the address c012df43 should point out the offending module. We know from the dump that the intelisec_serve process was running, and that it was doing a file-write. The traceback, read from the bottom up, shows the list of active calls at the time the failure occurred.
Since it is very unlikely that you are the first intelisec user to have encountered this problem, a search of Google and of the vendor's site would be a good first step.
The relevant source-code seems to be in arch/i386/fault.c where we are told that "the kernel tried to access some bad page. We'll have to terminate things with extreme prejudice." A few steps backward in the traceback should help to see why.
Last edited by sundialsvcs; 08-05-2005 at 01:51 PM.
Kernel map shows that address c012df43 is in function find_lock_page.
The application running is my own program. It uses threads to write into files. One file one thread. It also uses the v4l2 driver to grab images. Never have a problem with it before I started using a P4 CPU on an Intel motherboard. I have two identical machines, both are troubled.
This is the first time it had this problem, usually the program crashes or stops responding, but only on this full Intel platform.
Could it be a sign of system bus overload, irq or dma problems?
It could be a subtle driver issue that only shows up on this particular system. Can you check with the author of the driver to see if perhaps this isn't a known problem. In general, nothing from user space should be able to bother the kernel unless something in the kernel itself isn't behaing quite correctly. Is this accessing a device such as a camera connecting to a USB port via this driver? Perhaps the driver has some sort of race condition, given that you are using threads, but it's hard to say without knowing a bit more about your application.
I use 4 PCI analog frame grabbers to grab images. There are 2 IDE drives to store the images. There are no graphics card, cd, floppy or any other device connected. I use ext3 filesystem.
The machine mainly runs ok, but time to time scrambles the filesystem, depending on load, crashes the application, or hangs the applications network connection. It happens about once a day. The operating system seems runs fine. There are no users, or other applications running, no X, hardly any process beside the main application.
Usually there is nothing in the kernel log. Ocasonally - about 2 a week - the bttv module logs some errors. I have spent a month on tracking down the source of instability. This is the first time I see the Oops inthe kernel log and wondering, that my problems are comming not from my application, but some hardware problem, however I have 2 idetical machines behaving very similarly. They are Intel 915 motherboards with P4 cpu and 256 RAM. I also tested the RAM.
I guess the kernel Oops does not bring me closer to the solution. It only tells me that there is a problem which propably not originates from my code, but could be caused by conflicts between kernel modules, or a hardware problem.