Bug 119737 - SCHED_FIFO freezes system even if priority lower than shell
SCHED_FIFO freezes system even if priority lower than shell
Status: CLOSED WONTFIX
Product: Red Hat Linux
Classification: Retired
Component: kernel (Show other bugs)
9
i386 Linux
high Severity high
: ---
: ---
Assigned To: Arjan van de Ven
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-04-01 16:49 EST by oumer
Modified: 2005-10-31 17:00 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-09-30 11:41:51 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description oumer 2004-04-01 16:49:11 EST
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 11:41:51 EDT
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/

Note You need to log in before you can comment on or make changes to this bug.