Description of problem:
SCHED_FIFO program that is in a constant loop seems to freeze the
system till it is done, or if it is infinite loop system has to be
rebotted even when running the shell at the highest priority.

Version-Release number of selected component (if applicable):
I am using glibc-2.3.2-27.9 on readhat 9, kernel version 2.4.20-18.9

How reproducible:
Always

Steps to Reproduce:

1. get schedutils package if you don't have already to get chrt
program to change real time priority
2.gcc sched_test.c -o sched_test
4. run the shell at highest priority
   chrt -f -p 99 pidofshell 
3.chrt -f 10 sched_test time_to_sleep&

/sched_test.c/
#include <sys/time.h>
#include <time.h>
#include <stdlib.h>
#include <stdio.h>
#include <unistd.h>

int main(int argc, char *argv[])
{
  int end_time;
  struct timeval now;

  if (argc < 2) 
    {
      end_time = 1;
    }
  else
    {
      end_time = atoi(argv[1]);
    }

  gettimeofday(&now, NULL);

  end_time += now.tv_sec + 1;

  do{
    gettimeofday(&now, NULL);
    
  }while (now.tv_sec < end_time);

  printf("bye now.\n");
  return 0;
}


Actual results:
system freezes till the sleep_time is done in the sched_test program.

Expected results:
be able to stop program as the shell is running at high priority

Additional info:

No keyboard input is displayed though it will be displayed once the
program is done, showing that the keyboard interrupts handlers are
working but some kind of priority inversion seems to be in effect as X
is somehow involved. And based on the discussion I found at this site
http://www.ussg.iu.edu/hypermail/linux/kernel/0306.2/0635.html
I tried to raise the priority of the keventd to 99 , sched_fifo
but still I get no change. Books and man pages on real time scheduling
just mention that running a shell of max priority will take care of
lower priority real time threads that have run wild.

I have also tried it with Fedora test2 distribution based on kernel
2.6 with the same effect.  Also the kernel fix that was mentioned in
the http://www.ussg.iu.edu/hypermail/linux/kernel/0306.2/0986.html
doesn't seem to help.