[Xenomai-core] [BUG] x86 TSC emulation broken

[Xenomai-core] [BUG] x86 TSC emulation broken

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 1251 bytes --]

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 generating code).

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.

Before spending "some" time on a clean (in contrast to what I just read
in foreign code...) fix for Xenomai, I would like to cross-check if this
emulation is still considered useful. No one seems to use it, otherwise
we should have received complaints much earlier.

Fix it or drop it?

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 249 bytes --]

Re: [Xenomai-core] [BUG] x86 TSC emulation broken

[Philippe Gerum]

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.

> 
> 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.

> 
> Before spending "some" time on a clean (in contrast to what I just read
> in foreign code...) fix for Xenomai, I would like to cross-check if this
> emulation is still considered useful. No one seems to use it, otherwise
> we should have received complaints much earlier.
> 
> Fix it or drop it?
> 
> Jan
> 
> _______________________________________________
> Xenomai-core mailing list
> Xenomai-core@domain.hid
> https://mail.gna.org/listinfo/xenomai-core
-- 
Philippe.

Re: [Xenomai-core] [BUG] x86 TSC emulation broken

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 1670 bytes --]

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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]

Re: [Xenomai-core] [BUG] x86 TSC emulation broken

[Philippe Gerum]

On Sun, 2006-07-23 at 22:52 +0200, Jan Kiszka wrote:
> 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?

Unfortunately, we can't do that. The relevant code is in
arch/i386/kernel/time.c, do_slow_gettimeoffset(), you just can't
abstract this from the kernel sanely. It's a recurring issue with any
Adeos port over x86, and this got more complex with 2.6.

Btw, it's not an emulation issue that Adeos processes that way, it's
about dealing with the true owner of the PIT - as a non-virtualizable
resource -, i.e. Linux, or some domain above it. When Linux does not
"own" the PIT, it should refrain from touching it, period; and that's
what this code actually ensures. This is consistent with
ipipe_tune_timer(), which on some archs, is even used to tell Linux that
some domain is grabbing the timer for its own use (e.g. ia64).

>  Then I would happily leave it up to you. :)

I've a fix pending for the do_slow_gettimeofset() issue in 2.4 (2.6 is
fine). Adeos could export kd_mksound too, even if it's a terminally ugly
way of fixing this, but I have no better approach at hand.

> > 
> >> 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.

I recall having once thoroughly debugged the non-TSC case circa fusion
0.6.4 or so, this is why I'm relatively confident that we should be able
to reactivate such support without too much burden. It's confined in the
HAL, so the impact on the rest of the code is minimal.

>  There is
> just the likely theoretical case that there is no host tick (LAPIC +
> emulated TSC? Not configurable, is it?).
> 

Nope; in the LAPIC case, the hw must provide a TSC anyway.

> Jan
> 
-- 
Philippe.