Problems with timer behavior moving from Wheezy to Jessie

We’ve been using the Beaglebone Black running Wheezy 7.9 to replace an old legacy piece of hardware, but need it to be backwards compatible.
We have it working and everything is fine, BUT…

We’d really like to move it over to Jessie so we can use the cheaper Green unit (having trouble with the SPI with Green/Wheezy).

But here’s the problem: Moving over to Jessie (even on the BB-Black) throws off our signal timing. For example when we get
a certain byte of serial data we’re supposed to respond with our own in ~16ms. Code runs fine in Wheezy, in Jessie it responds in over 30ms.
Deal breaker, won’t work with the system. I seeing that Wheezy was calling ‘rt-code’ so made sure to update Jessie with the 4.1x-TI-RT kernel.
No help. Has anyone had experience with this?

I’m setting up a repetitive timer and a signal action that is called when the timer expires.

ala (brief code follows so you can see the exact stuff)

//Timer variables
#include <sys/time.h>

struct sigaction sa;
struct itimerval timer;

void InitializeTimers()
{
//Install timer_handler as the signal handler for SIGVTALRM
memset(&sa, 0, sizeof (sa));
sa.sa_handler = &timer_handler;
sigaction(SIGALRM, &sa, NULL);

timer.it_value.tv_sec = 0;
timer.it_value.tv_usec = TLI_MaxInterval+(TLI_MaxInterval/4)*(MyTLI_Addr-1);

timer.it_interval.tv_sec = 0;
timer.it_interval.tv_usec = TLI_MaxInterval;

setitimer(ITIMER_REAL, &timer, NULL);
}

I reset this timer every time I get a byte on the serial port.

This is some of the system info Wheezy vs. Regular Jessie

Jessie Settings (Default)
root@beaglebone:~# cat /boot/config-uname -r | grep HZ
CONFIG_NO_HZ_COMMON=y

CONFIG_HZ_PERIODIC is not set

CONFIG_NO_HZ_IDLE=y

CONFIG_NO_HZ_FULL is not set

CONFIG_NO_HZ is not set

CONFIG_RCU_FAST_NO_HZ=y
CONFIG_HZ_FIXED=0
CONFIG_HZ_100=y

CONFIG_HZ_200 is not set

CONFIG_HZ_250 is not set

CONFIG_HZ_300 is not set

CONFIG_HZ_500 is not set

CONFIG_HZ_1000 is not set

CONFIG_HZ=100

root@beaglebone:~# cat /boot/config-uname -r | grep HIGH_RES_TIMERS
CONFIG_HIGH_RES_TIMERS=y

root@beaglebone:~# uname -a
Linux beaglebone 4.4.9-ti-r25 #1 SMP Thu May 5 23:08:13 UTC 2016 armv7l GNU/Linux

Wheezy
root@beaglebone:~# cat /boot/config-uname -r | grep HZ
CONFIG_NO_HZ=y

CONFIG_RCU_FAST_NO_HZ is not set

CONFIG_OMAP_32K_TIMER_HZ=512
CONFIG_HZ=512

cat /boot/config-uname -r | grep HIGH_RES_TIMERS
CONFIG_HIGH_RES_TIMERS=y

root@beaglebone:~# uname -a
Linux beaglebone 3.8.13-bone79 #1 SMP Tue Oct 13 20:44:55 UTC 2015 armv7l GNU/Linux

root@beaglebone:~# cat /boot/config-uname -r | grep HIGH_RES_TIMERS
CONFIG_HIGH_RES_TIMERS=y

SO here is something you can try, while also documenting this problem for yourself, and others. Get a Wheezy install on sdcard, then update the kernel to a 4.1.x kernel, and then 4.4.x kernels. See where the difference is, IF it’s a cause of the kernel, or the rootfs.

My guess is that this may have something to do with the 4.4.x kernel, but it’s just a guess.

Loaded up my Wheezy image and installed the 4.1.26-ti-rt-r63 kernel. Broken just like the Jessie install. Great data point, Jessie isn’t the problem. Also tried the 4.1.18-bone-rt-r20 kernel. Same thing.

I’m starting to wonder if there’s not something going on with the way the new cape manager works? In order to get the UART up I have to pull and install the new overlays with git. Perhaps the new overlay doesn’t jump in quite as fast as the old?

No capemgr isn’t the problem. It’s either a missing kernel config option( by comparison ), or the configs are different. However . . .

$ apt-cache search linux-image |grep 3.8
linux-image-3.8.13-bone65 - Linux kernel, version 3.8.13-bone65
linux-image-3.8.13-bone66 - Linux kernel, version 3.8.13-bone66
linux-image-3.8.13-bone67 - Linux kernel, version 3.8.13-bone67
linux-image-3.8.13-bone68 - Linux kernel, version 3.8.13-bone68
linux-image-3.8.13-bone69 - Linux kernel, version 3.8.13-bone69
linux-image-3.8.13-bone70 - Linux kernel, version 3.8.13-bone70
linux-image-3.8.13-bone71 - Linux kernel, version 3.8.13-bone71
linux-image-3.8.13-bone72 - Linux kernel, version 3.8.13-bone72
linux-image-3.8.13-bone73 - Linux kernel, version 3.8.13-bone73
linux-image-3.8.13-bone74 - Linux kernel, version 3.8.13-bone74
linux-image-3.8.13-bone76 - Linux kernel, version 3.8.13-bone76
linux-image-3.8.13-bone77 - Linux kernel, version 3.8.13-bone77
linux-image-3.8.13-bone78 - Linux kernel, version 3.8.13-bone78
linux-image-3.8.13-bone79 - Linux kernel, version 3.8.13-bone79
linux-image-3.8.13-xenomai-r67 - Linux kernel, version 3.8.13-xenomai-r67
linux-image-3.8.13-xenomai-r69 - Linux kernel, version 3.8.13-xenomai-r69
linux-image-3.8.13-xenomai-r70 - Linux kernel, version 3.8.13-xenomai-r70
linux-image-3.8.13-xenomai-r71 - Linux kernel, version 3.8.13-xenomai-r71
linux-image-3.8.13-xenomai-r72 - Linux kernel, version 3.8.13-xenomai-r72
linux-image-3.8.13-xenomai-r76 - Linux kernel, version 3.8.13-xenomai-r76
linux-image-3.8.13-xenomai-r78 - Linux kernel, version 3.8.13-xenomai-r78

Forgot to add . . .

$ uname -r
4.4.9-bone-rt-r10

Also keep in mind if you retrograde kernels, you’ll have to install the proper device tree compiler, and recompile all your device tree overlays against the proper version for 3.8.x

Forgot to add . . .

$ uname -r
4.4.9-bone-rt-r10

D’oh ! That’s not very useful . . .

$ sudo lsb_release -a
No LSB modules are available.
Distributor ID: Debian
Description: Debian GNU/Linux 8.4 (jessie)
Release: 8.4
Codename: jessie

I figure that probably is the issue, but as a microcontroller guy some of this gets past my expertise. (Bless you interrupt vectors, I’ll never complain about you again)

3.8.13-bone79 is the one I was using successfully.

Any idea what might be different in the 4.1.X rt kernels to cause this? All the info I’ve been able to find show that it should be able to work, although it obviously doesn’t.

When I’ve tried to use the 4.4.X bone kernels it actually just won’t boot into Linux at all, the LEDs don’t even turn on… No idea what’s up with that.

I can stick with Wheezy and 3.8.X but I’d really love to know what is causing this and how I can fix it. Never like being in the dark about hardware I rely on.

When I’ve tried to use the 4.4.X bone kernels it actually just won’t boot into Linux at all, the LEDs don’t even turn on… No idea what’s up with that.

It depends. How old is the Linux on the eMMC ? Older bootloaders will cause the board to lock up in u-boot. In order to get around this you need to either install a newer image on the eMMC, or backup MLO + u-boot.img to some place safe, then completely remove them from the eMMC.

Actually, you can press and hold the boot button too, to load the bootloaders from the sdcard. You can try that short term but long term you’ll want to deal with it how I explained above.

Got the 4.4.12-bone-rt-r11 kernel installed and running. Same issue. I figure it has to be something with the clock settings but I have little idea where to start

root@beaglebone:~# uname -a
Linux beaglebone 4.4.12-bone-rt-r11 #1 PREEMPT RT Thu Jun 2 02:50:56 UTC 2016 armv7l GNU/Linux

cat /boot/config-uname -r | grep HZ
CONFIG_NO_HZ_COMMON=y

CONFIG_HZ_PERIODIC is not set

CONFIG_NO_HZ_IDLE=y

CONFIG_NO_HZ is not set

CONFIG_HZ_FIXED=0
CONFIG_HZ_100=y

CONFIG_HZ_200 is not set

CONFIG_HZ_250 is not set

CONFIG_HZ_300 is not set

CONFIG_HZ_500 is not set

CONFIG_HZ_1000 is not set

CONFIG_HZ=100

cat /boot/config-uname -r | grep HIGH_RES_TIMERS
CONFIG_HIGH_RES_TIMERS=y