Since the process has received a SIGKILL, it will die when it returns from its current system call. Furthermore the kernel will make the process return as soon as it gets into a state where it can safely abort the system call. A process only remains in uninterruptible sleep (state
D) for a long time if something unusual is happening inside the kernel. For more information about unkillable processes, see What if 'kill -9' does not work?
One way to investigate what the process is doing is to run a diagnostic tool such as strace or dtrace or other similar tools, depending on your unix flavor. This will tell you what system call the process is making and with what arguments. For example, you might see something like this:
strace: Process 2833351 attached
This tells you that the process is currently reading from file descriptor 3. The next step would be to find out what's on this file descriptor, for example with
lsof -p2833351 or with
ls -l /proc/2833351/fd/3. This could point to the origin of the problem, for example a non-responding NFS server or a buggy disk controller that left the filesystem driver in an unexpected state.
You may also find clues in the system logs. The clues may be difficult to find because this is unusual behavior that can be caused by very different things that would have very different telltale signs. It could be a kernel bug directly related to what the process is doing, an unrelated kernel bug that corrupted some memory, defective RAM that corrupted some memory, a defective peripheral such as a disk drive that isn't responding when it should, etc.