I have also observed some conditions like this, but this generally happens when kernel data structures are inconsistent and things like this. Example, if you build a filesystem and try to insert the module and then mount a device having that fs, then if doing some read you get a NULL pointer access, because of which the module is in inconsistent state, then after that running "df" command hangs and you get the same situation. You can produce conditions like this if you don't return anything in the read operations for a filesystem's read_super function and there are lot many ways to get this... Thanks. Sumit. On Tue, 14 Sep 2004 Learner wrote : >Hi , > > How to kill processes hanging in a blocked state as >shown below :- > >100 D root 3810 1 0 78 0 - 355 end > 06:51 ? 00:00:00 df > >The stack trace is as below :- > >df D C5AE9DA0 160 3810 1 >4241 31874 (NOTLB) >Call Trace: [<f89db2a4>] __rpc_execute [sunrpc] 0x204 >(0xc5ae9d48) >[<f89d7596>] rpc_call_setup_Rsmp_f8ecb729 [sunrpc] >0x46 (0xc5ae9d64) >[<f89d7479>] rpc_call_sync_Rsmp_f3c0f1eb [sunrpc] 0x69 >(0xc5ae9d70) >[<f89d748a>] rpc_call_sync_Rsmp_f3c0f1eb [sunrpc] 0x7a >(0xc5ae9d90) >[<f89d7680>] call_reserveresult [sunrpc] 0x0 >(0xc5ae9de4) >[<f89da410>] rpc_run_timer [sunrpc] 0x0 (0xc5ae9e04) >[<f89fa019>] nfs3_proc_statfs [nfs] 0x59 (0xc5ae9e40) >[<f89eda97>] nfs_statfs [nfs] 0x37 (0xc5ae9e90) >[<c0144759>] vfs_statfs [kernel] 0x59 (0xc5ae9f2c) >[<c01447cb>] sys_statfs [kernel] 0x3b (0xc5ae9f44) >[<c01073e3>] system_call [kernel] 0x33 (0xc5ae9fc0) > > Even a kill -9 as root does not eliminate these >processes . > > Also the stack trace shows that it is not >in "sleep_uninterruptible" . > > Any pointers would help . > >Regards > > > >_______________________________ >Do you Yahoo!? >Declare Yourself - Register online to vote today! >http://vote.yahoo.com > >-- >Kernelnewbies: Help each other learn about the Linux kernel. >Archive: http://mail.nl.linux.org/kernelnewbies/ >FAQ: http://kernelnewbies.org/faq/ >
