Description of problem: A process can consume 99.9% of the CPU, when it ought to be blocked; it stays in state 0. Version-Release number of selected component (if applicable): 2.6.12-1.1456_FC4 (from "uname -r") How reproducible: This was fairly easy to reproduce, once I had rebuilt crash. This has occured in other ways too. I rebuilt crash(8) and then did crash> foreach bt and hit the <spacebar> key a few times in rapid succession and then stopped. This left me in a state somewhat equivalent to more(1). A kernel stack trace (from a second instance of "crash") looks like: PID: 8993 TASK: ffff810058d247c0 CPU: 0 COMMAND: "crash" #0 [ffff81002b86fd38] schedule at ffffffff8032d36e #1 [ffff81002b86fe00] pipe_wait at ffffffff8018a16d #2 [ffff81002b86fe50] pipe_writev at ffffffff8018b19c #3 [ffff81002b86fef0] pipe_write at ffffffff8018b25f #4 [ffff81002b86ff10] vfs_write at ffffffff8017efc0 #5 [ffff81002b86ff40] sys_write at ffffffff8017f4b3 #6 [ffff81002b86ff80] tracesys at ffffffff8010e89e RIP: 0000003ecb6bc090 RSP: 00007fffffc1d238 RFLAGS: 00000246 RAX: ffffffffffffffda RBX: ffffffff8010e89e RCX: ffffffffffffffff RDX: 0000000000000048 RSI: 00007fffffc1d2b0 RDI: 000000000000000b RBP: 0000000000000048 R8: 00002aaaaaae19e0 R9: 0000003ecb70ba80 R10: 00007fffffc1fcf0 R11: 0000000000000246 R12: 00007fffffc1d2b0 R13: 00000000018e2990 R14: 0000000000000048 R15: 0000000000000048 ORIG_RAX: 0000000000000001 CS: 0033 SS: 002b Printing out the "state" field of the kernel's "struct task_struct" for the crash process shows that it equals 0 (i.e. "runnable"). (Both of these obtained, via crash(8) utility.) When the (above) problem does not occur, printing that same "state" field shows 1 ("interruptible"). Steps to Reproduce: 1. (See above) 2. 3. Actual results: crash process which should be blocked, waiting for keyboard input, remains runnable and therefore sucks up all the idle CPU time. Expected results: crash process should be blocked, waiting for keyboard input. Additional info:
[This comment added as part of a mass-update to all open FC4 kernel bugs] FC4 has now transitioned to the Fedora legacy project, which will continue to release security related updates for the kernel. As this bug is not security related, it is unlikely to be fixed in an update for FC4, and has been migrated to FC5. Please retest with Fedora Core 5. Thank you.
A new kernel update has been released (Version: 2.6.18-1.2200.fc5) based upon a new upstream kernel release. Please retest against this new kernel, as a large number of patches go into each upstream release, possibly including changes that may address this problem. This bug has been placed in NEEDINFO state. Due to the large volume of inactive bugs in bugzilla, if this bug is still in this state in two weeks time, it will be closed. Should this bug still be relevant after this period, the reporter can reopen the bug at any time. Any other users on the Cc: list of this bug can request that the bug be reopened by adding a comment to the bug. In the last few updates, some users upgrading from FC4->FC5 have reported that installing a kernel update has left their systems unbootable. If you have been affected by this problem please check you only have one version of device-mapper & lvm2 installed. See bug 207474 for further details. If this bug is a problem preventing you from installing the release this version is filed against, please see bug 169613. If this bug has been fixed, but you are now experiencing a different problem, please file a separate bug for the new problem. Thank you.
(this is a mass-close to kernel bugs in NEEDINFO state) As indicated previously there has been no update on the progress of this bug therefore I am closing it as INSUFFICIENT_DATA. Please re-open if the issue still occurs for you and I will try to assist in its resolution. Thank you for taking the time to report the initial bug. If you believe that this bug was closed in error, please feel free to reopen this bug.