Re: [Xenomai-help] no-brainer issue found, but not solved

[Jan Kiszka <jan.kiszka@domain.hid>]

[-- Attachment #1: Type: text/plain, Size: 2341 bytes --]

Steven Seeger wrote:
> Here are the routines in question:
> 
> low priority:
> 
> for(;;) {
>     /* regular rf watchdogs */
>     outb(0x45, 0x????);
>     outb(0x6a, 0x????);
>     outb(0x7e, 0x????);
>                
>     outb(0, 0x????); //patient watchdog
>     outb(0, 0x????); //fault led
> 
>     flip_reg_bits(WRFPC, 0x????); //flash yellow led
>                 
>     ????_flip_spi_bits(HV_STATUS_CONTROL, HV_WDOG_STROBE_MONITOR);
>                 
>     rt_task_wait_period();
> }
> 
> high priority:
> 
>     for(;;) {
>         if(motor_move) {
>             syslog(LOG_INFO, "about to lock up");
>             for(int i=0; i<100000000; i++);

This loop is always executed in secondary mode. This means it /may/ run
at the original high prio of that thread if syslog() did not trigger a
Linux reschedule, and it will run at prio 0 if syslog did so. This
depends on the arrival of Linux IRQs or the need of syslog to block on
some other Linux process.

Again, if you want RT for sure after a Linux call, use explicit mode
switching.

>             motor_move=0;
>         }
> 
>         rt_task_wait_period();
>     }
> 
> All function calls contain only inb or outb, no system calls. If I comment
> out the syslog call in the high priority thread, the yellow LED stops
> flashing completely. Otherwise, it flashes every second, with the
> periodicity of the higher priority thread.
> 
> I have another problem, too:
> 
> Using the same yellow LED flashing thread, if I start up a LOWER priority
> task like this, I can see jitter on my LED strobe line on the scope once a

Also as rt-thread?

> second. Why would the lower priority thread making a system call affect the
> higher priority one?
> 
> for(;;) {
>     syslog(LOG_INFO, "sleeping 1");
>     sleep(1);
> }

Something seems to be broken, but it is hard to analyse remotely if in
the test setup or the system.

Please replace your LED thread in this scenario with the latency test
tool, running at the same frequency. Collect the worst-case data. If
they show quirks as well, consider applying the tracer patch and catch
the abnormal jitters via "latency -f". You can tune the number if
backtrace_points in /proc/ipipe/tracer until you get a significant time
interval into the trace.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]