zawada@cs.qmw.ac.uk (Simpson) (03/19/91)
Does it gets hate me, or is there really something in it?
I've installed minix 1.5 so far on 3 DIFFERENT types of machine
which seem to like minix, two unknown clones, (386 and 286) and
an RM 386. Each one has accepted the kernel okay, and has run
all the tests O.K.
But....
Whenever I run elvis or vi, after a while, I get the message
Alarm clock......
Vi aborts, and mucks up the tty!
From what I can deduce vi is receiving an alarm clock signal
from somewhere, I'll be damned if I know where!
As this doesn't seem to be the machines I'm using, other
hardened vi users must be having the same problem.
Does anybody know why this happens, and a solution to it?
--
Mark Simpson Snail Mail:
Internet: zawada%cs.qmw.ac.uk@nsfnet-relay.ac.uk | Computer Science Dept
JANET: zawada@uk.ac.qmw.cs | QMW, University of London
/ | Mile End Road
/ | London E1 4NS
\/ | United Kingdomberggren@eecs.cs.pdx.edu (Eric Berggren) (03/21/91)
zawada@cs.qmw.ac.uk (Simpson) writes: >Does it gets hate me, or is there really something in it? >I've installed minix 1.5 so far on 3 DIFFERENT types of machine >which seem to like minix, two unknown clones, (386 and 286) and >an RM 386. Each one has accepted the kernel okay, and has run >all the tests O.K. >But.... >Whenever I run elvis or vi, after a while, I get the message >Alarm clock...... >Vi aborts, and mucks up the tty! >From what I can deduce vi is receiving an alarm clock signal >from somewhere, I'll be damned if I know where! >As this doesn't seem to be the machines I'm using, other >hardened vi users must be having the same problem. It hates me too. I have received the message a couple of times, but I am not certain why. If you get any e-mail regarding it, please forward it to me, else I look for it on the net. Thanx. -e.b. ============================================================================== Eric Berggren | "The force of the 'Dark Side' eminates from Computer Science/Eng. | the ominous DeathStar looming overhead." berggren@eecs.cs.pdx.edu | - Down with AT&T! -
kevin@nuchat.sccsi.com (Kevin Brown) (03/21/91)
In article <2019@pdxgate.UUCP> berggren@eecs.cs.pdx.edu (Eric Berggren) writes: >zawada@cs.qmw.ac.uk (Simpson) writes: > >>Does it gets hate me, or is there really something in it? > >>I've installed minix 1.5 so far on 3 DIFFERENT types of machine >>which seem to like minix, two unknown clones, (386 and 286) and >>an RM 386. Each one has accepted the kernel okay, and has run >>all the tests O.K. > >>But.... > >>Whenever I run elvis or vi, after a while, I get the message > >>Alarm clock...... > >>Vi aborts, and mucks up the tty! > >>From what I can deduce vi is receiving an alarm clock signal >>from somewhere, I'll be damned if I know where! > >>As this doesn't seem to be the machines I'm using, other >>hardened vi users must be having the same problem. > > It hates me too. I have received the message a couple of times, >but I am not certain why. If you get any e-mail regarding it, please >forward it to me, else I look for it on the net. Thanx. When I was running Minix-88 ("wimpy Minix" :-), I was able to consistently recreate this behavior by hitting <esc> when I was in movement mode (as opposed to insert mode, which is where you're SUPPOSED to hit <esc>). That made me suspect that the call to disable the alarm clock signal failed for some reason. Beats me. Since I've been running Minix-386, I haven't had this problem (though I had other problems with it, but not since I upgraded to Elvis 1.4). In addition to the above problem, it looks like elvis and virecover were compiled using two different versions of _doprnt() (i.e., the central library call for printf() and it's ilk). Needless to say, that particular problem is quite annoying, as virecover won't properly recover your editing session once the alarm clock bug has hit you. Recompiling elvis (1.3) may make the problem you mention go away, but I never bothered to try (I was a LOT more careful about when I hit <esc>, though) since I knew I'd be upgrading to Minix-386 anyway, and would work on the problem then if it surfaced (it didn't). Hope this helps... > Eric Berggren | "The force of the 'Dark Side' eminates from > Computer Science/Eng. | the ominous DeathStar looming overhead." > berggren@eecs.cs.pdx.edu | - Down with AT&T! - -- Kevin Brown Disclaimer: huh? nuchat!kevin@uunet.uu.net csci31f7@cl.uh.edu Minix -- the Unix[tm] of the 90's. System V -- the Multics of the 90's. :-)
schlut@oski.toppoint.de (Olaf Schlueter) (03/23/91)
zawada@cs.qmw.ac.uk (Simpson) writes: > Does it gets hate me, or is there really something in it? > > Whenever I run elvis or vi, after a while, I get the message > > Alarm clock...... > > Vi aborts, and mucks up the tty! > Vi, as many other unix programms, does the usual version 7 unix trick for non-blocking read, which is: wind up the alarm-clock, call read, which returns either one or more chars or EOF, if the alarm call happens during the call. If read is not aborted by the alarm clock, an alarm(0) should stop the clock, but there is a bug in Minix, so this fails. I discovered this on MINIX 1.5 ST, as distributed by PH, when I was programming an uucico. I got around this bug without fixing the kernel by setting a SIGALRM interrupt handler dummy routine (which does nothing) whenever I used alarm for non-blocking IO. You cannot avoid the alarm signal but this way you can prevent it from stopping your program. The other feature of alarm, that another alarm-call with a value > 0 resets the alarm clock to the new value, works. You can watch the bug working in: #include <signal.h> int donothing() {signal(SIGALRM,donothing);} int main() { char c; int n; #ifdef FOOL_THE_BUG signalSIGALRM,donothing); #endif do { alarm(1); n = read (1,&c,1); alarm(0) } while( n > 0); } run this program and hold the "a" key pressed. In normal v7 Unix that programm will stop within a second after releasing "a". In Minix the program runs 1 second, whether you press "a" or not. (I keyed that program in from my long-term memory, it has been a couple of months since I used it to verify the bug - so there maybe a mistake in it.) -- Olaf Schlueter, Sandkuhle 4-6, 2300 Kiel 1, FRG, schlut@oski.toppoint.de "Someone is always the evil in the land, and then the good guys are marching, the eyes full of sand, into a holy war." Konstantin Wecker
schlut@oski.toppoint.de (Olaf Schlueter) (03/27/91)
So, thanks to Bruce Evans, I have to correct myself: schlut@oski.toppoint.de (Olaf Schlueter) writes: >You can watch the bug working in: > do { > alarm(1); n = read (1,&c,1); alarm(0) } while( n > 0); >} >run this program and hold the "a" key pressed. In normal v7 Unix that >programm will stop within a second after releasing "a". In Minix >the program runs 1 second, whether you press "a" or not. I've been wrong :-( This simple version fails as for the buffering read. If you set RAW-Mode (and by the way read from stdin rather then stdout, bad typ-O), everything works as expected from v7 unix. Bruce thinks, there is a race condition, the alarm may expire after the read, but before the alarm(0) call - this would explain, why it is only seen on slow machines. -- Olaf Schlueter, Sandkuhle 4-6, 2300 Kiel 1, FRG, schlut@oski.toppoint.de "Someone is always the evil in the land, and hhhcor: : :an be v7rourourI I IufufusasasherVd (d (d
kirkenda@eecs.cs.pdx.edu (Steve Kirkendall) (03/31/91)
In article <4@oski.toppoint.de> schlut@oski.toppoint.de (Olaf Schlueter) writes: >>You can watch the bug working in: >> do { >> alarm(1); n = read (1,&c,1); alarm(0) } while( n > 0); >>} > >Bruce thinks, there is a race condition, the alarm may expire after the >read, but before the alarm(0) call - this would explain, why it is >only seen on slow machines. There *is* a race condition in the [corrected version of] the above code. However, that isn't what's happening in elvis. Any signal that is caught will either have no effect on the flow of control in the main program, or it may cause certain slow system calls to return with an EINTR error. Since elvis catches the SIGALRM signal, an alarm that happens during the read() will cause the return to have an EINTR error; and an alarm between the read() and the alarm() will have no effect. For Elvis to die from a SIGALRM signal, it must be receiving two signals after a single non-zero alarm() call. This sounds like a bug in the kernel. As Bruce and Olaf say, it may be due to a race condition there, although the fact that I've *NEVER* seen this happen on my Atari makes me wonder. As a work-around, I suggest you try recompiling elvis after inserting a "signal(SIGALRM, dummy)" call just before the "alarm(0)" in tio.c. Or, you could just ":set keytime=0" to disable this whole timeout business. ------------------------------------------------------------------------------- Steve Kirkendall kirkenda@cs.pdx.edu Grad student at Portland State U.