--------------------------------------------------
John Meacham http://synergy.caltech.edu/
john@foo.net
--------------------------------------------------
On Sat, 3 May 1997, Kristofer T. Karas wrote:
>
> Synopsis: The RC5 challenge client (and other non-page-fault,
> non-blocked programs) lock 2.1.36 while running.
>
> 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).
>
>
>