Hi, I am facing following problem and was wondering if somebody could help me out. I reference our char driver below but the question I really have is about sleep/wake_up mechanism. So, I thought somebody who is aware of this can help me. BTW, this is 2.6.10.
Our char driver(pretty much like all other char drivers) does a poll_wait() and returns status depending on whether data is available to be read. Even though some data is available to be read(verified using one of our internal commands), the select() never wakes up, inspite of any no. of messages sent. To understand this, I was looking at the code of select vs wake_up_interruptible(). I feel I am misunderstanding some part of the kernel code but will be glad if somebody can point it out. My understanding: The do_select() sets the state of task to TASK_INTERRUPTIBLE and calls the driver's poll entry point. In our poll(), let's say immediately after we determine that there's nothing to be read, some data arrives causing a wake_up_interruptible() on another CPU. The wake up happens in the context of process sending the data. Since the receiving process was already added to the list of listeners, from looking at the code of try_to_wake_up(), it looks like it can set the state of the receiving process to TASK_RUNNING(I don't see any lock preventing this). After this happens, the receiving process goes to sleep (because of schedule_timeout called by do_select) but state is still set to TASK_RUNNING. In this state, when another message arrives, the wake_up_interruptible will not wake the process because of following code in try_to_wake_up() ? old_state = p->state; if (!(old_state & state)) goto out; The above situation seems simplistic so I'm wondering what I am missing here ? Thanks, Ravi - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
