Conference turris::digital_unix

8782.0. "kmem_debug = 1 causes Alphastation 500/400 clock to lose time" by NETRIX::"[email protected]" (Jarkko Hietaniemi) Tue Feb 11 1997 05:08

A customer of mine found quite undeniable proof that turning
kmem_debug on causes the clock on his Alphastation 500/400 to
lose time.

The Alphastation is running Digital UNIX 4.0B, FW 6.3.
It has a medium workload; software development, editing,
compilations, the like.

A couple of weeks ago they noticed that it was slowly losing
time at the rate of a couple of minutes / 24 hours. That did
not make any sense and we decided to strip away any custom
configurations done so far. As the about the last thing we found,
there was, for some forgotten reason (none of the system
admins of the customer confessed...), kmem_debug = 1
in the /etc/sysconfigtab.

Well, we took that off, and rebooted. And for more than a week
the clock stayed perfectly in time.

Last Friday we put the kmem_debug=1 back in and this Monday
the clock was behind by about 18 minutes. They had left some
diskx:s running to the local disks to get crude simulations
for a normal workload when they left work on Friday but those
had(succesfully) finished by Saturday and the whole
machine stood completely idle Sat-Sun.

Summa summarum: I give you the following facts.

1. They had kmem_debug on, the machine lost time.
2. They turned it off, the machine stayed in time for more
   than a week.
3. They turned it on, the machine lost 18 minutes in 2.5 days.
4. No other configuration changes were made during that time.

Now, is this effect of kmem_debug known? Come to think of it,
where are the supposed effects of it documented?
Note the very latest available version of UNIX and FW.

-- 
Jarkko Hietaniemi Digital/Finland MCS/OSS DTN 879-4738
[email protected]   +358-(0)9-434 4738

[Posted by WWW Notes gateway]

We already swapped once the whole CPU board, that was the first
thing we suspected when the customer reported clock losing time.
When that did not help any, we started looking at the problem
from the software point of view.

[Posted by WWW Notes gateway]

    yes... this is a known issue with kmem_debug.  In general, running with
    kmem_debug kills performance and should only be used when tracking a
    kernel malloc corruption problem.
    
    Can this be fixed, maybe.  I would suggest you QAR it.
    
    /jim
    

Thanks for the reply. QARed as 51482.


[Posted by WWW Notes gateway]