Re: Stream of kernel messages: pid <n> is killed: exceeded RLIMIT_CPU

[christos%zoulas.com@localhost (Christos Zoulas)]

On Nov 13,  6:01pm, jarle%uninett.no@localhost (Jarle Greipsland) wrote:
-- Subject: Re: Stream of kernel messages: pid <n> is killed: exceeded RLIMIT

| christos%zoulas.com@localhost (Christos Zoulas) writes:
| > Ok. The root of the problem is:
| > 
| > | WARNING: negative runtime; monotonic clock has gone backwards
| > 
| > I have seen that on the windows virtual pc but nowhere else. What clock
| > does your alpha use, and can that go backwards?
| Good question.  Now that you mention it, I seem to recall that I
| have had problems with the clock on this system before.  It's a
| dual CPU CS20.  And I had to use sysctl.conf early in the boot
| process to set
| 
|   kern.timecounter.hardware=clockinterrupt
| 
| The choices available are:
| kern.timecounter.choice = PCC(q=1000, f=1249650000 Hz) clockinterrupt(q=0, 
f=1024 Hz) dummy(q=-1000000, f=1000000 Hz)
| 
| If I choose the PCC, I get the following effect:
| # while true; do date; sleep 1; done
| Sun Nov 13 17:57:41 CET 2011
| Sun Nov 13 17:57:41 CET 2011
| Sun Nov 13 17:57:42 CET 2011
| Sun Nov 13 17:57:43 CET 2011
| Sun Nov 13 17:57:43 CET 2011
| Sun Nov 13 17:57:44 CET 2011
| Sun Nov 13 17:57:45 CET 2011
| Sun Nov 13 17:57:46 CET 2011
| Sun Nov 13 17:57:46 CET 2011
| Sun Nov 13 17:57:47 CET 2011
| Sun Nov 13 17:57:48 CET 2011
| Sun Nov 13 17:57:48 CET 2011
| Sun Nov 13 17:57:49 CET 2011
| Sun Nov 13 17:57:50 CET 2011
| Sun Nov 13 17:57:50 CET 2011
| Sun Nov 13 17:57:51 CET 2011
| Sun Nov 13 17:57:52 CET 2011
| Sun Nov 13 17:57:52 CET 2011
| Sun Nov 13 17:57:53 CET 2011
| Sun Nov 13 17:57:54 CET 2011
| Sun Nov 13 17:57:54 CET 2011
| Sun Nov 13 17:57:55 CET 2011
| Sun Nov 13 17:57:56 CET 2011
| Sun Nov 13 17:57:56 CET 2011
| Sun Nov 13 17:57:57 CET 2011
| Sun Nov 13 17:57:58 CET 2011
| Sun Nov 13 17:57:58 CET 2011
| Sun Nov 13 17:57:59 CET 2011
| 
| So, something is very fishy when it comes to time-keeping on the
| alpha.

Yes, this is horrible. Perhaps we are missing clockinterrupts? How can
the clock go backwards though? I also don't understand why we clear the
clock in each loop. I would think that the code should look like:

clear
for (i = 0; i < 4; i++)
        wait for set, clear;
        start = getcounter;
        wait for set, flear;
        end = getcounter;
        diff[i] = end - start;
freq = ((diff[2] + diff[3]) * 16) / 2;

Not what we have now:

for (i = 0; i < 4; i++)
        clear
        wait for set, clear;
        start = getcounter;
        wait for set, flear;
        end = getcounter;
        diff[i] = end - start;
freq = ((diff[2] + diff[3]) / 2) * 16;

Does this make a difference in the computed frequency if you change it?

Index: mcclock.c
===================================================================
RCS file: /cvsroot/src/sys/arch/alpha/alpha/mcclock.c,v
retrieving revision 1.17
diff -u -u -r1.17 mcclock.c
--- mcclock.c   1 Jul 2011 19:22:35 -0000       1.17
+++ mcclock.c   13 Nov 2011 18:08:31 -0000
@@ -102,10 +102,11 @@
        /* set interval 16Hz to measure pcc */
        (*sc->sc_mcwrite)(sc, MC_REGA, MC_BASE_32_KHz | MC_RATE_16_Hz);
 
+       /* clear interrupt flags */
+       (void)(*sc->sc_mcread)(sc, MC_REGC);
+
        /* Run the loop an extra time to prime the cache. */
        for (i = 0; i < NLOOP; i++) {
-               /* clear interrupt flags */
-               (void)(*sc->sc_mcread)(sc, MC_REGC);
 
                /* wait till the periodic interrupt flag is set */
                while (((*sc->sc_mcread)(sc, MC_REGC) & MC_REGC_PF) == 0)
@@ -120,7 +121,7 @@
                ctrdiff[i] = pcc_end - pcc_start;
        }
 
-       freq = ((ctrdiff[NLOOP - 2] + ctrdiff[NLOOP - 1]) / 2) * 16 /* Hz */;
+       freq = ((ctrdiff[NLOOP - 2] + ctrdiff[NLOOP - 1]) * 16 /* Hz */) / 2;
 
        /* restore REG_A */
        (*sc->sc_mcwrite)(sc, MC_REGA, reg_a);