On Sun, 2006-08-27 at 16:22 +0200, Philippe Gerum wrote: > 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.
... provided you also enable CONFIG_X86_LOCAL_APIC for solving the oneshot timing issue. > > > Regards, > > Steve > > -- Philippe. _______________________________________________ Xenomai-help mailing list [email protected] https://mail.gna.org/listinfo/xenomai-help
