Downgrading to 3.1.0 doesn't help so in summary, removing the enable-kvm cmdline option and adding -no-hpet seems to allow Xenomai to startup at least. Will now start the latency tests, ect...
Rob Miller [email protected] (919)721-3339 On Wed, Oct 23, 2019 at 3:52 PM Rob Miller <[email protected]> wrote: > I found that if I remove the -enable-kvm and add -no-hpet, I'm able to get > Xenomi up-n-running on the stock xenomai-images. Adding -no-hpet alone > didn't help. Also, when the enable-kvm is disabled, the bootup time is > ~10-20 slower, but does boot. > > Further, just removing the enable-kvm flag, results in the stock image > never booting...or at least I gave up after 5 min's waiting. > > I will try to downgrade QEMU to 3.1.0 > > Rob Miller > [email protected] > (919)721-3339 > > > On Wed, Oct 23, 2019 at 12:07 PM Rob Miller <[email protected]> > wrote: > >> Mine a little newer >> >> QEMU emulator version 4.0.50 >> Copyright (c) 2003-2019 Fabrice Bellard and the QEMU Project developers >> >> Rob Miller >> [email protected] >> (919)721-3339 >> >> >> On Wed, Oct 23, 2019 at 9:26 AM Gylstorff Quirin via Xenomai < >> [email protected]> wrote: >> >>> >>> >>> On 10/23/19 2:48 PM, Rob Miller via Xenomai wrote: >>> > 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. >>> > >>> What qemu version do you use? >>> >>> For our tests we use >>> QEMU emulator version 3.1.0 (Debian 1:3.1+dfsg-8+deb10u2). >>> >>> >>> Quirin >>> >>> -- >>> Siemens AG >>> Corporate Technology >>> CT RDA IOT SES-DE >>> >>> >>> >>>
