dunbar@cs.hw.ac.uk (Neil Dunbar) (05/04/89)
Has anyone written a version of 'megartc' for MINIX-ST that can read the time from a Microdeal external ROM port real time clock? If so, could you mail it to me (source or binary, I don't care). Failing that, could someone more knowledgeable on the hardware than me (i.e. anyone) tell me how the RTC makes its data available to the ST, and I can maybe write a MINIX hack to read the clock. Thanks in advance, Neil Dunbar ----------------------------------------------------------------- Neil Dunbar |ARPA:dunbar@hw.cs.ac.uk Computing Science, |UUCP:..!mcvax!ukc!hwcs!dunbar Heriot-Watt University, |JANET:dunbar@uk.ac.hw.cs Edinburgh. | -----------------------------------------------------------------
DeadHead@cup.portal.com (Bruce M Ong) (05/06/89)
I got a question...
is minix's sleep() broken, or it's because I dont know
exactly what sleep does?
I have two programs
--- test1.c ---
main()
{
sleep(50);
}
--- test2.c ---
main()
{
int i = 0;
while (i < 10)
{
++i;
print("\nGoing to sleep for a while");
sleep(3);
printf("\nI am now awake");
}
}
if you execute the programs like this
$test1 &
130
$test2
Then test2 will terminate after looping few times, but
test1 will never wake up...
I havent tried it on other unix systems, yet... am I doing
something wrong with sleep()? I remember reading somewhere
in the text saying the wake up call does not know which one
to wake up, it just sends a wake up signal.. is that why?
I am using sleep() to implement a printer spooler (the daemon
scans the directory every several seconds); and I am also
using creat(2) to create queue locks - if it cant lock a queue file
it will sleep 2 seconds or so and try again. But after
running the queue program, the printer daemon just slips
into a coma... Does anybody else have the problem? I am using
MINIX 1.2 for the AT.
bruce deadhead@cup.portal.commjs@cbnewsl.ATT.COM (Mike Scheutzow) (05/09/89)
> Article 1432 of comp.os.minix: > I got a question... > > is minix's sleep() broken... > Then test2 will terminate after looping few times, but > test1 will never wake up... > bruce deadhead@cup.portal.com There was a bug in sleep() for minix-pc v1.2, and it may be in your system as well. Chip Roberson posted the problem and the fix a few months ago; it is appended. I make no claims about the accuracy of this information. Mike S. att!chnewsl!mjs -------------------------------------------------------------------- xFrom att!rutgers!rochester!udel!mmdf Thu Dec 15 04:28:03 1988 xPath: whuts!att!rutgers!rochester!udel!mmdf xFrom: csrobe@cs.wm.edu (Chip Roberson) xNewsgroups: comp.os.minix xSubject: sleep() [SIGALRM] bug in 1.2 xMessage-ID: <5983@louie.udel.EDU> xDate: 15 Dec 88 09:28:03 GMT xSender: usenet@udel.EDU xLines: 71 There is a bug in the 1.2 Version of PC Minix (that I have). You can determine if you have the bug by running the following code: if (fork() == 0) while (1) { putchar('c'); fflush(stdout); sleep(1); } else while (1) { putchar('p'); fflush(stdout); sleep(2); } if the ONLY output you see is something like: cpc then you have the same bug. NB: This bug will effectively kill /etc/update by breaking its sleep/wake-up loop! The problem is in mm/signal.c/check_sig at lines 6824-6842, where mm searches "through the proc table for processes to signal". for(...) { ... if (proc_id > 0 && proc_id != rmp->mp_pid) send_sig = FALSE; ... /* SIGALARM is a little special. When a process exits, a clock signal * can arrive just as the timer is being turned off. Also, turn off * ALARM_ON bit when timer goes off to keep it accurate. */ if (sig_nr == SIGALRM) { if ( (rmp->mp_flags & ALARM_ON) == 0) continue; rmp->mp_flags &= ~ALARM_ON; } if (send_sig == FALSE || rmp->mp_ignore & mask) continue; ... } The problem occurs when there are two alarms pending at the same time and an alarm goes off for the process deeper/later in the process table. The first check, determines that the signal is not for this process (proc_id != rmp->mp_pid) and sets a flag (send_sig = FALSE). Later on, it checks to see if this is an ALARM signal. If it is, then it makes sure that the process is still there and that it is still waiting for a signal. [BUT, at this point, we know that this process is not the correct process.] Well, if mm sees that this process has it's ALARM bit on (and /etc/update always will, and it will always be lower than any other user process!) it will turn off the ALARM_ON bit thinking that this process is about to be awoken. Well the last line, above, realizes that the signal really isn't for this process and goes to the next iteration of the for-loop. ERGO: an ALARM signal for process N will clear all outstanding ALARMs for any process i, INIT_PROC_NR < i < N. The fix is to move if (send_sig == FALSE || rmp->mp_ignore & mask) continue; before if (sig_nr == SIGALRM) { I would have sent diffs but that was just too much trouble to get them to a networked machine. cheers, -c ------------------------------------------------------------------------- Chip Roberson ARPANET: csrobe@cs.wm.edu Dept of Comp. Sci. csrobe@icase.edu College of William and Mary BITNET: #csrobe@wmmvs.bitnet Williamsburg, VA 23185 UUCP: ...!uunet!pyrdc!gmu90x!wmcs!csrobe -------------------------------------------------------------------------
DeadHead@cup.portal.com (Bruce M Ong) (05/10/89)
>> Article 1432 of comp.os.minix: >> I got a question... >> is minix's sleep() broken... >> Then test2 will terminate after looping few times, but >> test1 will never wake up... >> bruce deadhead@cup.portal.com > >There was a bug in sleep() for minix-pc v1.2, and it may be in your >system as well. Chip Roberson posted the problem and the fix a few >months ago; it is appended. I make no claims about the accuracy of >this information. > >Mike S. >att!chnewsl!mjs Thanks for sending the bug fix. I and my fellow OS students here at San Jose State thank you... On a related note. We ordered the MINIX the first month of 1989 from Prentice Hall - we got the license to distribute the source since each one of the students here in the OS class bought a coyp of the book. But we got 1.2, instead of 1.3. Now my prof has to try to get the 1.3 (he didnt know it was out by 1st of jan. )