[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <b647ffbd0710211025k1e5935a2ra6886724872437c8@mail.gmail.com>
Date: Sun, 21 Oct 2007 19:25:10 +0200
From: "Dmitry Adamushko" <dmitry.adamushko@...il.com>
To: "Jeff Garzik" <jeff@...zik.org>
Cc: "Ingo Molnar" <mingo@...e.hu>, "Chuck Ebbert" <cebbert@...hat.com>,
"Linux Kernel Mailing List" <linux-kernel@...r.kernel.org>
Subject: Re: [2.6.23] tasks stuck in running state?
On 20/10/2007, Jeff Garzik <jeff@...zik.org> wrote:
> Chuck Ebbert wrote:
> > On 10/19/2007 05:39 PM, Jeff Garzik wrote:
> >> On my main devel box, vanilla 2.6.23 on x86-64/Fedora-7, I'm seeing a
> >> certain behavior at least once a day. I'll start a kernel build (make
> >> -sj5 on this box), and it will "hang" in the following way:
> >>
> >
> > Can you try to strace the hanging task?
>
> Well, to the system it's running, so that doesn't do much of anything...
>
> >
> > 8482 pts/0 S+ 0:00 \_ /bin/sh /garz/repo/misc-2.6/scripts/hdrcheck.sh /garz/repo/misc-2.6/usr/include /garz/repo/misc-2.6/usr/include/linux/kernelcapi.h /garz/repo/misc-2.6/usr/include/linux/.check.kernelcapi.h
> > 8484 pts/0 R+ 3:10 \_ grep ^[ \t]*#[ \t]*include[ \t]*< /garz/repo/misc-2.6/usr/include/linux/kernelcapi.h
> > 8486 pts/0 S+ 0:00 \_ cut -f2 -d<
> > 8487 pts/0 S+ 0:00 \_ cut -f1 -d>
> > 8488 pts/0 S+ 0:00 \_ egrep ^linux|^asm
> > [jgarzik@...tzel misc-2.6]$ strace -p8484
> > Process 8484 attached - interrupt to quit
> [sits there, chewing up CPU grepping a 47-line header file]
I think, the following information would be helpful :
(1) # cat /proc/PID/stat ; sleep 5; cat /proc/PID/stat
as we could know :
- whether utime or/and stime keeps increasing ;
- one of the fields is actually 'eip' ... so we could, hopefully, more
or less precisely localize the area of the code where it's looping.
(do_task_stat() in fs/proc/array.c)
(2) # cat /proc/sched_debug;
and
# cat /proc/PID/sched
(if your kernel has CONFIG_SCHED_DEBUG=y)
(3) is anything else able to run on this CPU (as I understand it's
SMP) or the task does completely locks it up.
again, one of the fields of /proc/PID/stat is the CPU# on which the
task is currently active.
Let's start a buzy-loop task on this cpu and see wheather it's able to
make any progress (TIME counter in 'ps')
# taskset -c THIS_CPU some_busy_looping_prog
TIA,
--
Best regards,
Dmitry Adamushko
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists