Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!mcsun!unido!mikros!mwtech!joerg
From: joerg@mwtech.UUCP (Joerg Werner)
Newsgroups: comp.os.minix
Subject: Re: Bizarre SIGINT behavior (PC Minix)
Summary: a two line patch for this problem
Message-ID: <1041@mwtech.UUCP>
Date: 12 Jan 91 10:42:24 GMT
References: <1991Jan6.042939.10130@menudo.uh.edu>
Reply-To: joerg@mwtech.UUCP (Joerg Werner)
Organization: MIKROS Systemware, Darmstadt/W-Germany
Lines: 79

In article <1991Jan6.042939.10130@menudo.uh.edu> uace0@menudo.uh.edu.UUCP
 (ATARI Computer Enthusiasts) writes:

>I thought that less was the cause of the problem, but it's not.  Do the
>following:
>	sh </dev/tty
>
>Now hit the INT key.  Your shell and your subshell will go away, and you'll
>get the login prompt back.  In fact, when I do this with the basic P-H 1.5.10
>system, I get "login:" repeatedly printed on my screen until I hit <return>, 
>at which point it stops and gives me the login prompt and will then accept 
>a login.

I have a similar problem, maybe the same:-).  It occurs if /etc/rc
executes the following program:

#include <signal.h>
trap() {exit(1);}
main()
{
	char buf[256];

	signal(SIGALRM,trap);
	alarm(5);
	printf("Hit <Return> or wait 5 seconds.\n");
	read(0,buf,sizeof(buf));
	exit(0);
}

If I wait and the alarm signal occurs, the login prompt is printed
repeatedly and no login is accepted.

>Aha, I thought, this means that the ACTUAL terminal has to be "opened" like
>the rest.  The only place in which it is really proper to distinguish
>between devices is in fs/device.c, right?  So I went there and implemented
>code that would, if it saw that /dev/tty was being opened, fix up the
>message and pass it on such that the actual control terminal would be 
>opened.  Since doing a "sh </dev/ttyN" works, I figured that this was the
>problem.  I was wrong.  If it's related to the actual inode of the device

The problem lies indeed in fs/device.c. More specifically rw_dev2() is the
hog. The global pointer `fp' points to the callers process table [Minix
Manual, line 16266]. If the caller is a user process everything works fine.
But sometimes MM calls the FS, and `fp' points to MM's process table, of
course. That's the case if a signal is sent to a process. If the process
is hanging on a system call (READ for example) the FS must be informed.

But what happens if rw_dev2() is called now? The controlling tty of the MM
is checked:-((

This means that fp->fs_tty is always 0, and the message is sent to the MEM
task. A hanging read-call is  n o t  terminated!!!

Luckily there is a easy way to find out which process table we need. The
message contains the process number! Please have a look at the patch. I
hope this helps (and if, please let me know).

Ciao Joerg

PS: I'm using MINIX ST 1.5.[10.3].
    BTW, the result of two days work, was a 2 line patch :-)
------------------------ cut here -------------------------------
*** /usr/src.1.5.10.3/fs/device.c	Tue Nov 20 21:19:33 1990
--- /usr/src/fs/device.c	Thu Dec 27 16:26:58 1990
***************
*** 188,193 ****
--- 188,196 ----
   */
  
    int task_nr, major_device;
+   register struct fproc *fp;
+ 
+   fp = &fproc[ mess_ptr->PROC_NR ];
  
    if (fp->fs_tty == 0) {
  	mess_ptr->DEVICE = NULL_DEV;
------------------------ cut here -------------------------------
-- 
Joerg Werner, email: joerg@mwtech.UUCP, voice: 49-(0)6151-37 33 66