[Crash-utility] ps: issue with "waking" and "parked" task states?

Dave Anderson anderson at redhat.com
Mon Jun 22 17:33:50 UTC 2015



----- Original Message -----
> 
> 
> ----- Original Message -----
> > Hi Dave,
> > 
> > I recently looked into a linux 4.0 dump where the "ps" command prints "??"
> > for the state field of several tasks:
> > 
> > crash> ps
> >     741    660   1      7b408000      ??   0.0    2152   2592  chcpu
> >     748      2  24      20c284f00     IN   0.0       0      0
> >     [migration/24]
> >     752      2  22      20b1ccf00     ??   0.0       0      0
> >     [migration/25]
> > 
> > Looking at the "task_struct->state" I get the following:
> > 
> >  crash> task_struct 7b408000 | grep state
> >    state = 0x100,
> >  crash> task_struct 20b1ccf00 | grep state
> >    state = 0x200
> > 
> > Looking into include/linux/sched.h states are defined as follows:
> > 
> >  #define TASK_RUNNING            0
> >  ...
> >  #define TASK_WAKING             256
> >  #define TASK_PARKED             512
> > 
> > When I issue "help -t" I get the following:
> > 
> >            RUNNING:   0 (0x0)
> >      INTERRUPTIBLE:   1 (0x1)
> >    UNINTERRUPTIBLE:   2 (0x2)
> >            STOPPED:   4 (0x4)
> >    TRACING_STOPPED:   8 (0x8)
> >             ZOMBIE:  32 (0x20)
> >               DEAD:  16 and 32 (0x10 and 0x20)
> >           WAKEKILL:  64 (0x40)
> >             WAKING: 128 (0x80)  <- Should be 256?
> > 
> > I have not digged deeper, but at least wanted to report this issue.
> > Perhaps you see the problem at once.
> > 
> > Michael
> > 
> > 
> 
> I see it now.  The states are gathered from the kernel's task_state_array[].
> So on a 3.9-based kernel, for example, it's this:
> 
> crash> p task_state_array
> task_state_array = $1 =
>  {0xffffffff81a01959 "R (running)", 0xffffffff81a01965 "S (sleeping)",
>  0xffffffff81a01972 "D (disk sleep)", 0xffffffff81a01981 "T (stopped)",
>  0xffffffff81a0198d "t (tracing stop)", 0xffffffff81a0199e "Z (zombie)",
>  0xffffffff81a019a9 "X (dead)", 0xffffffff81a019b2 "x (dead)",
>  0xffffffff81a019bb "K (wakekill)", 0xffffffff81a019c8 "W (waking)",
>  0xffffffff81a019d3 "P (parked)"}
> crash>
> 
> And for example, here's the 3.10 kernel's declaration:
> 
> /*
>  * The task state array is a strange "bitmap" of
>  * reasons to sleep. Thus "running" is zero, and
>  * you can test for combinations of others with
>  * simple bit tests.
>  */
> static const char * const task_state_array[] = {
>         "R (running)",          /*   0 */
>         "S (sleeping)",         /*   1 */
>         "D (disk sleep)",       /*   2 */
>         "T (stopped)",          /*   4 */
>         "t (tracing stop)",     /*   8 */
>         "Z (zombie)",           /*  16 */
>         "X (dead)",             /*  32 */
>         "x (dead)",             /*  64 */
>         "K (wakekill)",         /* 128 */
>         "W (waking)",           /* 256 */
>         "P (parked)",           /* 512 */
> };
> 
> where on a 4.0.5 kernel, the wakekill, waking and parked fields no longer
> exist in the array:
> 
> crash> p task_state_array
> task_state_array = $1 =
>  {0xffffffff81a73b42 "R (running)", 0xffffffff81a73b4e "S (sleeping)",
>  0xffffffff81a73b5b "D (disk sleep)", 0xffffffff81a73b6a "T (stopped)",
>  0xffffffff81a73b76 "t (tracing stop)", 0xffffffff81a73b87 "X (dead)",
>  0xffffffff81a73b90 "Z (zombie)"}
> crash>
> 
> This is the upstream kernel declaration:
> 
> static const char * const task_state_array[] = {
>         "R (running)",          /*   0 */
>         "S (sleeping)",         /*   1 */
>         "D (disk sleep)",       /*   2 */

>         "T (stopped)",          /*   4 */
>         "t (tracing stop)",     /*   8 */
>         "X (dead)",             /*  16 */
>         "Z (zombie)",           /*  32 */
> };
> 
> Not sure where the wakekill, waking, and parked went yet though...
> 
> Dave

Looks like I should probably change the scheme to gather the state information
from the stat_nam[] string instead:

  #define TASK_STATE_TO_CHAR_STR "RSDTtXZxKWP"

  static const char stat_nam[] = TASK_STATE_TO_CHAR_STR;

Thanks for the heads-up.
  Dave




More information about the Crash-utility mailing list