I got a really odd situation .... was wondering if any1 came across it. 
The cpu time for the sched process is equal to the Virtual Machine uptime 
[ESX3.5] ... 
so even if i reboot the OS the ps -ef | grep sched will show like 300 minutes 
of cpu time.
Which will match exactly the lifetime/uptime of the virtual machine

Some1 familiar with the way cpu time is calculated would have a clue on how 
this could be possible and point me in the right direction.

A problem exists .... and i belive its related somehow to this ubnormality .... 
this is the only machine which shows the cpu time for the sched process higher 
then a few seconds. (27 typically)
Sched process cpu time in ps -ef | grep sched is always equal to the uptime of 
the virtual environment ..... which makes no sense ... 
What i mean is once i reboot the OS the sched process CPU time cant be higher 
then the OS uptime !!

The core problem is that this node is part of a 4 node cluster which has been 
happily running reliably for almost a year ... 
suddenly this one node panics almost every 3 hours ... the panic reason is a 
pm_tick delay EQUAL to the virtual machine uptime
..... so both the sched process cpu TIME and the pm_tick delay are equal ..... 
thus im assuming somehow related .... to a common root problem/anomaly.

Anything on how or what solaris is reading to end up calculating the cpu time 
ONLY for the sched process to be identical to the Virtual Machine (ESX3.5) 
uptime rather then the OS uptime ?

This message posted from opensolaris.org
zones-discuss mailing list

Reply via email to