On Sun, 2006-08-27 at 15:47 +0200, Steve Kreyer wrote: > Philippe Gerum wrote: > >> Moreover, and that's likely another reason for troubles here, you have > >> CONFIG_VT on. This normally unproblematic features collides with the TSC > >> emulation of Xenomai. > >> > > > > I'll jump on this, since this likely deserves some detailed > > explanations: > > > > The general problem with CONFIG_VT, is the tone generator it uses to > > send bell events to the user, issued by the keyboard management code. On > > x86, the related kernel code fiddles with the legacy programmable > > interrupt timer (PIT) to create an audible tone, specifically this > > chip's channels #0 and #2. > > > > And the problem starts here: when there is no TSC available to the > > kernel, whether because there is none provided by the CPU, or its > > support has been disabled in the kernel configuration (i.e. > > CONFIG_X86_TSC unset), then Xenomai uses the PIT to emulate a kind of > > poor man's TSC, so that it can eventually get a monotonic clock. To this > > end, Xenomai will also use the PIT's channel #2, as a free running > > counter. Hence the conflict with CONFIG_VT. > > > > But there is more: On x86, Xenomai also uses the PIT's channels #0 and > > #1 when undergoing the oneshot timing mode, exclusively for kernel > > configurations which do not provide APIC support (i.e. > > CONFIG_X86_LOCAL_APIC unset, because none of CONFIG_X86_UP_APIC and > > CONFIG_SMP are set). In such a case, the PC speaker management code > > generating the tone will badly conflict with the Xenomai system timer > > too, causing all sorts of erratic behaviours, since both step on each > > other's toes when programming the PIT's channel #0. > > > > With Linux 2.4, the sound generator is reached through a callback > > pointer, so Xenomai just routes the latter to a dummy routine, and we > > are done. With Linux 2.6, the callback has disappeared from the vanilla > > kernel, and sound event requests are sent to the input sub-system for > > processing, where we have currently no hack to void them. This is the > > reason why disabling CONFIG_VT entirely is recommended when there is a > > risk of conflict (which is rather drastic, I agree). > > > > To sum up: > > - The CONFIG_VT issue is in fact a conflict between the regular PC > > speaker code and Xenomai. > > - It is strictly a x86 issue. > > - It is automatically solved by Xenomai over Linux 2.4, and should be > > solved by disabling CONFIG_VT entirely over Linux 2.6 for configurations > > which do not provide APIC or even TSC support, at least until Adeos > > eventually silences this code, on demand, to help us. > > > > Since you have a P4, you do have a local APIC on your chip, so you > > should enable it for a uni-processor configuration (CONFIG_X86_UP_APIC), > > since it has far better performances latency-wise than the legacy > > programmable interrupt controller. You also have a TSC, and the kernel > > should use it automatically, provided the P4 CPU is properly selected in > > your kernel configuration, as Jan pointed out. > > With this configuration, you should not have to care about CONFIG_VT > > anymore. > > > > > Ok I try to sum up the points to see if I understand your explanation right: > On an x86 architecture xenomai uses the PIT to emulate a tsc,
and provide oneshot timing support, > but the > PIT is also used by the VT to generate the speaker tone. And if I don't > disable CONFIG_VT, or the Linux speaker code, things get messed up. > But If I had an pentium architecture where tsc is provided, xenomai can > take care of this and directly uses the tsc supported by the pentium > chip, assumed that the kernel > is configured to a pentium. > Am I right, could you ack this? > Ack. > Regards, > Steve > -- Philippe. _______________________________________________ Xenomai-help mailing list [email protected] https://mail.gna.org/listinfo/xenomai-help
