Closed zultron closed 9 years ago
I didn't run into this issue with 3.16.7 when I built yesterday, and the default of Kconfig's entry for selfcalibration (yes) indicates it should have been run, but I didn't really pay attention to that.
From what I understand, withou calibration, you lose some precision and introduce some jitter. So it's not very good not to calibrate, but it's certainly something most people can live without.
I'll take a look at it and see if I can fix it.
Sorry for my ignorance. This is some sort of latency calibration? Wouldn't the result be different from machine to machine? In that case, calibration shouldn't be done on the build host at build time, but rather on the application host at install or run time.
Actually you are perfectly right. The devs probably assumed everyone builds RTAI on their own.
Still, the calibration tool in the previous versions suffered from the same issue. You had to run the calibration tool, get the sched latency value and give it as a parameter when insmod
ing rtai_sched.ko
.
To that end, it is probably best then to disable selfcalibration for the debian package. Anyone that wants the precision would need to do the calibration locally.
I don't see a clean way around this.
I just sent an email to the mailing list explaining why this happens. In short, the developers apparently run make
with root permissions, so the self calibration works. Due to badly handling error cases, the failure in calibration is not reported, and manifests itself in having empty values for the calibration constants, hence the error from gcc.
Since you disable self calibration (which doesn't make sense for packaging RTAI as you discovered), you don't need to care about this.
I ran into issues similar to Alec's, and made the same fix. Was there any further resolution to that issue?
Will it be an issue turning
CONFIG_RTAI_SCHED_LATENCY_SELFCALIBRATE
off in packages? DoesCONFIG_RTAI_SCHED_LATENCY
need to be set, somehow, and if so, to what?