<div class="gmail_quote">On 30 March 2010 00:03, Tony Mountifield <span dir="ltr">&lt;<a href="mailto:tony@softins.clara.co.uk">tony@softins.clara.co.uk</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">In article &lt;hm3o5a$mno$<a href="mailto:1@softins.clara.co.uk">1@softins.clara.co.uk</a>&gt;,<br>
Tony Mountifield &lt;<a href="mailto:tony@softins.clara.co.uk">tony@softins.clara.co.uk</a>&gt; wrote:<br>
&gt;<br>
</div><div class="im">&gt; My main question at the moment is &quot;what mechanism could stall all RTP streams?&quot;,<br>
&gt; and a clue is the almost-exact five minutes for which it happens.<br>
<br>
</div><div class="im">Well, FINALLY, I have managed to discover what is causing this problem,<br>
although I haven&#39;t yet fixed it.<br>
<br>
The problem is in ztdummy. It is the one from zaptel-1.2.27, and has been<br>
compiled with USE_RTC. The OS is CentOS 4 with kernel 2.6.9-78.0.22.ELsmp.<br>
The system has a pair of quad-core E5420 Xeons.<br>
<br>
By monitoning /proc/interrupts every second, I have discovered that when<br>
the problem occurs, the RTC interrupts stop counting up. After exactly<br>
five minutes, they start up again. Obviously the lack of timing from<br>
ztdummy is causing Meetme and file streaming to stall.<br>
<br>
So, does anyone have any ideas why the RTC interrupt might stall for exactly<br>
five minutes? I have only ever seen it on this one system. Nothing is logged<br>
in any of the system logs at the time it occurs.<br>
<br>
I would quite like to try the HPET mode of ztdummy, but it looks like this<br>
requires a much newer kernel, 2.6.22, which is way newer than even CentOS 5.<br>
Is there any other way to do this?<br>
<br>
Thanks in advance for any ideas!<br><br></div></blockquote><div><br></div><div>This thread on vmware forums seems to describe your problem...</div><div><br></div><div><a href="http://communities.vmware.com/thread/77895?start=0&amp;tstart=0">http://communities.vmware.com/thread/77895?start=0&amp;amp;tstart=0</a></div>
<div><br></div><div><a href="http://communities.vmware.com/thread/77895?start=0&amp;tstart=0"></a>also includes a workaround of disabling hpet (hpet=disable or nohpet kernel params) to avoid the problem...</div><div><br></div>
<div>d </div></div>