[SOLVED] F11 freezes

[kalzoubi]

Hi,

I am using F11 (Kernel 2.6.30). My application reads data from A/D card once the card sends IRQ interrupt. Those interrupts are received once every 40 ms, if the system in the acquisition mode.

In this case, I have a module loaded to the kernel to handle those interrupts. Once an interrupt is received the module sends a signal to the my application in the user space (the code showed below).

The PROBLEM is that after data acquisition for a bout an hour Linux freezes (i.e. cannot use mouse, keyboard, etc).

One of the solutions I tried is to boot the kernel with the "noapic" option. This caused the system to hangs after about 4 hours of data acquisition. Perhaps, because my IRQ is now handled by only CPU0 as shown in file /proc/interrupts (i.e. my system has two CPUs).

How to work around this problem.

Please note that my IRQ handler in the kernel module is written as follows, in case I have a problem with it:

static irqreturn_t e5000_irq_handler(int irq, void *dev_id, struct pt_regs * regs) {
struct siginfo info;
struct task_struct *tsk = NULL;
memset(&info, 0, sizeof (struct siginfo));
info.si_signo = SIGUSR1;
info.si_code = SI_KERNEL;

rcu_read_lock();
tsk = find_task_by_vpid(Acq_Data_PID);
rcu_read_unlock();

if (tsk != NULL) {
send_sig_info(SIGUSR1, &info, tsk);
}
return IRQ_HANDLED;
}

[leigh123linux]

Moved to EOL (End Of Life) Versions

[jpollard]

May not have anything to do with the problem.

How does the memory usage track?

Curious... why does the driver not read the D/A converter itself?

[kalzoubi]

Hi,

Using the "ps aux" command the application process memory usage stays at 0.2 %. However, the CPU usage keeps increasing. For example, in 30 mins the CPU usage increased from 1.2 % to about 16.2% (just before the system hangs).

To answer your question, I read the data in the user space since I need to process and view it to the user anyway. Do you think I should have this module read and buffer the data. After that signal the application. Will that matters.

Thanks

[jpollard]

Personally, I think it would get better use to have the driver read the D/A and put it in a buffer for the application.

If the application is not real time (and displaying to a user isn't real time), then having an application thread open a file descriptor and read data (blocking on the read when there is no data) would have less overhead. Once the application unblocks (data available) it can process one or more samples at once without having to block for each sample.

Less overhead - no signal delivery, catching signal, then reading data... with the possibility of missing signals (too slow) and missing data values (added to input buffer instead).

Will this fix your problem? don't know - it may depend on what is actually going wrong. It would seem to be a memory leak (but in the kernel, not userspace), but I can't tell.

stevea is more likely to have an idea, I believe he works in embedded systems and so is more familiar with kernel behavior there.

[kalzoubi]

Thanks much for the inputs. Although, I like your idea so I'll keep it. However, it didn't fix my problem.

I observed that the USB stick does not flash once inserted during system hanging. To me, this means that it is not detected by the hardware. Could it be a hardware problem?

[kalzoubi]

Thanks again. Sorry due to none related issues, I thought your suggestion didn't fix my problem, but it did. Thus, the problem was because of sending a signal from the driver module.

Regards,