Interestingly, I also get the exact same failure on the xenomai-images pulled from the git repo.
the errors start right off the bat with: tsc: Fast calibration failed tsc: Unable to calibrate against PIT tsc: No reference (HPET/PMTIMER) available .. .. clocksource: hpet: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 19112604467 ns hpet clock event registered tsc: Fast calibration failed tsc: Unable to calibrate against PIT tsc: No reference (HPET/PMTIMER) available tsc: Marking TSC unstable due to could not calculate TSC khz <--- kiss of death I believe as Cobalt sees the flag and errors out .. .. hpet0: at MMIO 0xfed00000, IRQs 2, 8, 0 hpet0: 3 comparators , 64-bit 100.000000 MHz counter clocksource: Switched to clocksource hpet .. .. [Xenomai] scheduling class idle registered [Xenomai] scheduling class weak registered [Xenomai] scheduling class tp registered [Xenomai] scheduling class pss registered [Xenomai] scheduling class quota registered [Xenomai] scheduling class rt registered I-pipe: high-resolution clock not working <--- I believe this looks at the TSC marked as being unstable flag set above and bails out [Xenomai] init failed, code -19 I dug into the unstable issues on my VM (ie: non xenomai-images repo), and found that tsc_read_refs(*ref, hpet) is where the problem lies in either whether using using hpet or not, either the returned ref value is 0 (when hpet == 1), or the amount of time is took to read from PM (hpet == 0) took forever (ie: 100000+ cycles) which is at least 2x the SMI_THRESHOLD vlaue that is allowed in the code. My guess is that even when using the stock xenomai-images directly, I'll have the same situation. I read about SMI issues, and given the cycle allowance for SMI interruptions in the tsc_read_refs() functio, I focused on SMI. In my VM (ie: non-stock images), I set the linux cmdline option xenomai.smi=disabled, but no love there either. Given that both my VM and the stock images fail, I'm now thinking QEMU version, or underlying host CPU issues, or TBD, is the issue, and thought I'd first ask the community for guidance as to how to proceed. Thoughts ideas will be greatly appreciated. Rob Miller [email protected] (919)721-3339 On Fri, Oct 11, 2019 at 1:32 PM Jan Kiszka <[email protected]> wrote: > On 11.10.19 19:25, Rob Miller via Xenomai wrote: > > Things were working well with my server but when I went to a VM, it fails > > complaining about no high-res timers. > > > > I figure it must be a CPU that I have chosen and am wondering what others > > are using. I googled for quite a while but can't seem to find any info > so I > > thought I would post here for some advice. > > > > Have a look at https://gitlab.denx.de/Xenomai/xenomai-images for working > configurations for x86, ARM and ARM64 as well as the related QEMU > parameters - or use that image directly. > > Jan > > -- > Siemens AG, Corporate Technology, CT RDA IOT SES-DE > Corporate Competence Center Embedded Linux >
