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/cd93c8a0b50008690e4c116ddb9215b1ea0f36d1 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@xxxxxxxxxx) 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 > > -- Crash-utility mailing list Crash-utility@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/crash-utility
