Details:
Sorry if this has been reported before, but I stumbled upon an odd bug
in 2.1.36 triggered by running the RC5 challenge client. While it was
running (solid run, no I/O), most other activity on the system locked
up. No, it's not a NICE problem, as existing processes continue
executing; it's just that when some process runs solidly without page
faults or other blocking activity, new process creation appears to be
suspended.
How to reproduce:
echo "main() { while 1; }" > foo.c ; gcc -o foo foo.c ; foo
Now switch virtual consoles to get a login prompt, enter your
username, and wait for the password prompt. If your system responds
as mine does, you won't get the password prompt until you SIGTERM your
running test program.
I noticed from running `top` that the %CPU field remained at 0.0 for
all processes, including the hard-running test case. I don't know if
there's any correlation.
System details:
2.1.36 on non-SMP system (HP Vectra-4 5/133) with all updates as
specified in Documentation/Changes, libc 5.4.23, procps 1.01,
modutils 2.1.34, fairly vanilla kernel config save for having kerneld
operating. The system seems to work just fine in all other respects,
other than some spurious warning messages (lots of TCP/IP martians,
and a lone "Ugh at c0113114" at startup).
______________________________________________________________________________
Kristofer Karas - Sr Clinical Sys Admin - Beth Israel Deaconess Medical Center
mailto:ktk@ktk.bidmc.harvard.edu http://ktk.bidmc.harvard.edu/~ktk/
AMA/CCS, DoD, RF900RR, HawkGT, !car - Will design LISP machines for food :-)
"Health nuts are going to feel stupid someday, lying in hospitals dying
of nothing." -- Redd Foxx
------------------------------------------------------------------------------