Bug 119737

Summary: SCHED_FIFO freezes system even if priority lower than shell
Product: [Retired] Red Hat Linux Reporter: oumer <oumer>
Component: kernelAssignee: Arjan van de Ven <arjanv>
Status: CLOSED WONTFIX QA Contact: Brian Brock <bbrock>
Severity: high Docs Contact:
Priority: high    
Version: 9CC: oumer
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2004-09-30 15:41:51 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description oumer 2004-04-01 21:49:11 UTC
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.

Comment 1 Bugzilla owner 2004-09-30 15:41:51 UTC
Thanks for the bug report. However, Red Hat no longer maintains this version of
the product. Please upgrade to the latest version and open a new bug if the problem
persists.

The Fedora Legacy project (http://fedoralegacy.org/) maintains some older releases, 
and if you believe this bug is interesting to them, please report the problem in
the bug tracker at: http://bugzilla.fedora.us/