Philippe Gerum wrote: > On Sun, 2006-07-23 at 19:28 +0200, Jan Kiszka wrote: >> Hi, >> >> I happened to switch on some CPU type that enabled the Xenomai's TSC >> emulation code. The result was an ugly lock-up: endless loop in the >> timer IRQ handler. >> >> The reason: the TSC emulation collides with the VT sound output / the PC >> speaker driver. Over 2.6, one can easily avoid this my switching off >> CONFIG_INPUT_PCSPKR. 2.4 requires to export and than manipulate >> kb_mksound (the pointer to the sound gen* >> erating code). > > There is an issue in the Adeos 2.4 patch (1.2-05) which is not > preventing the kernel from poking into the 8254 registers to determine > the current time offset.
But the TSC emulation itself is not an Adeos service. Shouldn't it be better moved? Then I would happily leave it up to you. :) > >> The latter pointer rang some bell. I once fixed a broken RTAI build due >> to that code. So I pulled out vulcano and actually found the related >> code + an extension of the original ipipe patch to export kb_mksound. I >> guess it would have been too complicated for Paolo to explain the reason >> of this export to us... >> >> Anyway, this digging revealed another potential breakage in the >> emulation code: RTAI takes care to read the emulated TSC at least once >> per 50 ms, to avoid overflows I assume. Xenomai does not. > > Mm, through the host timer service, it should at least each 10ms period. Yeah, true. I probably got blinded by the existing RTAI code. There is just the likely theoretical case that there is no host tick (LAPIC + emulated TSC? Not configurable, is it?). Jan
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
