Re: 2.1.36 Bug report: Hard-run processes lock out others.

John Meacham (
Fri, 2 May 1997 07:15:31 -0700

I get the same problem when i compile the kernel... I posted it to the
list before with the mention of kernel exceptions which i got along with
it but they are probably unrelated... in any case i noticed the same
console lock up...

John Meacham

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).