11:58 a.m.
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
12:22 p.m.
----- 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
12:33 p.m.
New subject: ps: issue with "waking" and "parked" task states?
----- 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
2:16 p.m.
New subject: ps: issue with "waking" and "parked" task states?
Hi Michael,
I have to thank you again for the report. As it turns out, the task state
gathering and display functionality needed several updates and fixes that
are queued for crash-7.1.2:
https://github.com/crash-utility/crash/commit/cd93c8a0b50008690e4c116ddb9...
Several fixes associated with the gathering and display of task
state. Without the patch:
(1) The "ps" command's ST column shows "??" for tasks in the
TASK_WAKING state.
(2) The "ps" command's ST column shows "??" for tasks in the
TASK_PARKED state in Linux 3.14 and later kernels.
(3) The STATE field of the initial system banner and the "set"
command are incorrect if the task state has the TASK_WAKING,
TASK_WAKEKILL modifier, or TASK_PARKED bits set in Linux 3.14
and later kernels.
(4) The "foreach DE" task identifier fails if a task with a PID
number of 0xDE (222) exists.
(5) The "foreach" command's "SW", "PA",
"TR" and "DE" task
identifiers inadvertently select all tasks in kernel versions
that do not have those states.
(6) The "help -t" output would display incorrect values for the
TASK_WAKEKILL, TASK_WAKING and TASK_PARKED states in Linux 3.14
and later kernels.
Lastly, support for the TASK_NOLOAD modifier introduced in Linux 4.2
has been added to STATE field of the "set" command and the initial
system banner.
(anderson(a)redhat.com)
Dave
----- Original Message -----
----- 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
3444
days inactive
3445
days old
devel@lists.crash-utility.osci.io
3 comments
2 participants
participants (2)
-
Dave Anderson -
Michael Holzheu