Thanks Dave for that reply. While i try out registering handlers for all possible signals, I forgot to mention this point in my previous email. The userspace is waiting on a select call. As per the system design, the kernel module interrupts when there is a data intended to the user (via poll in kernel). If this could be the cause for the userspace getting a signal, then typically what signal is generated to the process to invoke select to inform that the I/O is ready. Is it SIGIO? Regards, Vijay On Mon, Apr 4, 2011 at 9:18 PM, Dave Hylands <dhylands@gmail.com> wrote:
Hi Vijay,
On Sun, Apr 3, 2011 at 9:27 PM, Vijay Ram Chitrapu <chitrapu.vijayram@gmail.com> wrote:
Hi Experts,
I have a system in which there is a only 1 user process and a corresponding kernel module (driver) associated with it to send and receive data to the user process. In the kernel module, i have a semaphore to protect a critical section of code during the rx and tx paths. However, at some instance of code execution, the down_interruptible returns EINTR, which means that the user process has received some interrupt due to which the process has come out of sleep due to the signal it received, due to which the kernel module has not got the semaphore. At this point of time, i have no idea as to which signal has triggered the user process to come out of the sleep. Is there a way in which we can know which signal has a process received, without registering any user defined handler to it?
Any thoughts/ideas on debugging this problem can be of great help. Also please correct me if i am wrong in any of my understanding regarding down_interruptible.
The simplest way is to just register a signal handler for all possible signals (in the user program) and print out which one actually happened.
-- Dave Hylands Shuswap, BC, Canada http://www.davehylands.com