Hi Rajaram.... > <Raja> Since I was able to kill the process, I believe that it came > back to TASK_INTERRUPTIBLE. All right...but I really suggest to carefully check in what state the bash currently at.... > <Raja> may be set_task_state does that by acquiring some lock > properly..?? just a wild guess. from what I see in more detail, looks like it is forcing the new value assignment (in this case, task state) to go directly to memory area and thus bypassing L1/L2 cache. I might be wrong, so you better check it by yourself. Hint: start by reading set_mb() > <Raja> hmm..I have to check whether insmod was not in zombie state. > But if the bash process received SIGCHLD and cleaned up insmod > properly.., it should have come to the next bash prompt.., right..? I am not sure, usually that's what happens (normally), but since we play with task state here, anything can happen IMHO. > <Raja> No. I am not doing anything to init process descriptor. > I am doing bash->parent = insmod. i.e I am just setting the parent > pointer of bash to point to its child...i.e insmod. So that bash > thinks that insmod is its parent. Silly me, yes you're right, you're actually making insmod as the new bash's parent. IMHO, I think a deadlock situation happens here. But, it is rather a surprise that even power button doesn't bring any effect. BTW, what do you do? Just making insmod as bash's parent? Or do you do anything else? I guess bash itself want to notify something to its parent (in this case, insmod) and since it no longer exists, something "funny" happen. regards Mulyadi -- Kernelnewbies: Help each other learn about the Linux kernel. Archive: http://mail.nl.linux.org/kernelnewbies/ FAQ: http://kernelnewbies.org/faq/
