I remembered I have an older box with a Wildcard TE12xP that uses the wcte12xp module with a newer 3.9.11 kernel that works perfectly.
I setup the problematic machine with the same kernel in the hope that this might be relevant. Unfortunately the same situation persists. I used the /proc/timer_stats to see how the timers were used: Timer Stats Version: v0.2 Sample period: 10.002 s .... 311, 15081 kworker/u:0 mod_timer (te12xp_timer) .... With the TE110P I couldn't find any entry.... It seems that the timing mechanism is different, it doesn't use mod_timer. I'm running out of ideas. Please help. Thanks, Mike On Tue, 2014-05-13 at 17:56 -0300, Mike Leddy wrote: > Thanks again Russ, > > Just a quick reply for now. > > No virtualization, but yes I am running a tickless kernel: > > # > # Processor type and features > # > CONFIG_NO_HZ=y > > Standard for debian kernels. I booted with nohz=off and the behaviour > changed. Unfortunately for the worse: > > # dahdi_test > Opened pseudo dahdi interface, measuring accuracy... > 66.653% 66.683% 66.683% 66.807% 67.705% 66.666% 66.651% 66.679% > 67.516% 66.882% 66.649% 66.657% 66.678% 66.668% 66.672% 66.664% > 66.675% 66.675% 66.659% 66.692% 66.631% 66.187% 66.650% 66.710% > 66.648% 66.633% 66.714% 66.638% 66.688% 66.794% 66.645% 66.696% > --- Results after 32 passes --- > Best: 67.705% -- Worst: 66.187% -- Average: 66.726523% > > Comparing the boot messages without nohz=off: > > [ 0.000000] hpet clockevent registered > [ 0.000000] Fast TSC calibration failed > [ 0.000000] TSC: Unable to calibrate against PIT > [ 0.000000] TSC: using HPET reference calibration > [ 0.000000] Detected 2593.456 MHz processor. > > and with nohz=off: > > [ 0.000000] hpet clockevent registered > [ 0.000000] Fast TSC calibration using PIT > [ 0.000000] Detected 2593.225 MHz processor. > > I am encouraged that we seem to be homing in on the problem. I need to > read up a bit more on the subject.... and look at possible power > saving issues on this machine. > > Best regards, > > Mike > > > On Tue, 2014-05-13 at 15:26 -0500, Russ Meyerriecks wrote: > > On Tue, May 13, 2014 at 7:28 AM, Mike Leddy <m...@loop.com.br> wrote: > > But on examination the /etc/init.d/dahdi start was only > > loading > > the dahdi module. > > > > > > With this in mind I might start looking around the system for things > > which might cause jitter in the servicing of system timer interrupts: > > > > > > Are you running under a virtualized environment? > > Are you running a tickless kernel? (maybe try adding nohz=off to your > > kernel boot parameters) > > Is there some sort of processor power saving or frequency scaling > > going on that interrupts the system timer? > > > > > > -- > > Russ Meyerriecks > > Digium, Inc. | Linux Kernel Developer > > 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA > > direct: +1 256-428-6025 > > Check us out at: www.digium.com & www.asterisk.org > > > -- _____________________________________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users