From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <4366F875.6050802@domain.hid> Date: Tue, 01 Nov 2005 06:09:09 +0100 From: Philippe Gerum MIME-Version: 1.0 Subject: Re: [Xenomai-core] Re: [Xenomai-help] General Xenomai / RTAI Skin Usage Questions References: <4366708B.8010501@domain.hid> <200511011227.03173.rlenglet@domain.hid> In-Reply-To: <200511011227.03173.rlenglet@domain.hid> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: "Xenomai life and development \(bug reports, patches, discussions\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Romain Lenglet Cc: xenomai@xenomai.org Romain Lenglet wrote: >>- A kernel option that causes Xenomai (or Adeos) to blatantly >>malfunction or even crash is a freaking BUG, and should be >>reported asap to the Xenomai-core list or the Adeos-main list. >>IOW, there is no such thing as options allowed to crash your >>box with Adeos/Xenomai because of some "don't care attitude"; >>would such bug happen, it must and will be fixed. All the >>people involved in contributing to both projects try to make >>sure that any option could be enabled without risking terminal >>damage to anyone's setup. The worst thing that should be >>allowed to happen is high latency spots, because some options >>might cause some hardware to interact badly with critical >>resources Adeos/Xenomai also happen manage. > > > Here is a kernel-option-related bug. > I am using a stock Debian-patched kernel with the standard Debian > kernel config, on Pentium M and Pentium 4 machines, + the latest > Adeos patch. > The Debian kernel configuration file, that has every option > enabled and everything as modules, works fine with Xenomai > except for one single option which must be disabled: > CONFIG_PCI_MSI > This option messes with the oneshot timer (timer freezes). > (thanks to Gilles to have found this out) > Could you confirm that this issue still happens with adeos-ipipe-2.6.13-1.0-05 or higher? > > Otherwise, my biggest source of problems is IRQ sharing between > realtime and non-realtime drivers: this predictably provokes > kernel panics. But Jan seems to be working on it. > Yes, this is another issue, more of a shortcoming of the current IRQ handling scheme than a bug. -- Philippe.