On Mon, March 26, 2018 5:12 pm, Christopher Obbard wrote:
Ah, I've been running mainline stable 4.14,
applied CONFIG_PREEMPT and
ran a cyclictest on three threads with no extra load. It was giving me
"ok" average latency, and terrible maximum latency.
That is exactly the point of the RT patches. "Most" of the time latency
is OK with the standard configuration options. If you don't mind losing
some data occasionally the standard kernel config options are probably OK.
This time I have a printk message of "GBLCTL
write error" every few us.
Every few microseconds? I took a quick look at the McASP documentation
and that register looks like a control register you would setup once when
starting the driver, and then not touch it again until you had to
reconfigure. If it is being written more than a couple of times something
is wrong. It is possible that something is triggering error handling to
kick in, it looks like that register has to be written again in certain
cases where clock synch is lost, or possibly lost. Without knowing more
details of how you configured clocking and what your hardware looks like I
can't say much more than that could be something to investigate.
Lesson learnt: use vendor BSP
Or Robert Nelson's (RCN), his kernel builds are probably at least as good
as TI and sometimes has additional features included.
Yeah, the rtirq script is handy. It will need some
tweaking for arm
boards, I think.
Should only need a change to which devices are included in the
RTIRQ_NAME_LIST string in /etc/sysconfig/rtirq (or maybe /etc/rtirq, I
don't remember where it would go in Debian).