Correction, stock images work by removing the enable-kvm and *NOT *adding the -no-hpet QEMU cmdline options.
also latency numbers are crazy with avg being 1678.126 usec w/ worst case being 15463.240usec at this point, I'm not sure which way to go: 1) do I hunt down issues in HPET failing w/ KVM mode enabled? 2) just go to dovetail 3) ??? Rob Miller [email protected] (919)721-3339 On Wed, Oct 23, 2019 at 5:02 PM Rob Miller <[email protected]> wrote: > 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 >>>> >>>> >>>> >>>>
