On 28 July 2002 09:35, Federico Sevilla III wrote:
> On Sun, Jul 28, 2002 at 06:22:46PM +0800, Federico Sevilla III wrote:
> > I have been noticing problems on two of my boxes here with some
> > processes somehow getting stuck in "D" state, which cannot be killed
> > even by a SIGKILL by root, and stay on running forever. I have noticed
> > the problem, so far, on 2.4.18-xfs and 2.4.19-rc2-xfs kernels.
>
> I do not know how small a tidbit this will be, but together with these
> processes stuck in state "D", there is a continuing rise in the load
> averages of the system as reported by various interfaces
> (top/uptime/w/phpSysInfo). On the system running 2.4.18-xfs this rose to
> up to 25 before I eventually rebooted the box.
>
> Another bit: on the 2.4.18-xfs box, the number of processes getting
> stuck in state "D" kept growing. Various `ps ax` and `sync` processes in
> particular, would get stuck and stall as I would issue them. It may be
> interesting to note that with 2.4.19-rc2-xfs, with which I had my "latest
> encounter" with this problem, no `ps ax` or `sync` processes got stuck.
> Only the couple of apt-method processes that got stuck (and any new ones
> I would launch in an attempt to download a package from the Internet for
> installation) were there.
D state processes are sitting in kernel code waiting for something
to happen. It is ok to sit in D state for milliseconds, it is acceptable
to sit for seconds. If those processes are stuck forever, it's a bug.
Capture Alt-SysRq-T output and ksymoops relevant part
Yes it means you should have ksymoops installed and tested,
which is easy to get wrong. I've done that too often.
-- vda - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Tue Jul 30 2002 - 14:00:28 EST