From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <4433C087.3020403@domain.hid> Date: Wed, 05 Apr 2006 15:05:11 +0200 From: Philippe Gerum MIME-Version: 1.0 Subject: Re: [Xenomai-core] Frozen timer IRQ References: <4432E540.1010108@domain.hid> <17459.46030.997560.684058@domain.hid> <4433BA43.7000807@domain.hid> In-Reply-To: <4433BA43.7000807@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: Philippe Gerum Cc: Jan Kiszka , xenomai-core Philippe Gerum wrote: > Gilles Chanteperdrix wrote: > >> Jan Kiszka wrote: >> > Hi, >> > > my colleagues and I need some hint where to continue our search >> for the >> > cause of a weird cleanup issue: >> > > An application of our robotics framework sometimes terminates >> (though >> > successfully) in a way that the system timer IRQ no longer arrives >> > afterwards or no re-program takes place anymore. All other Linux IRQs >> > are fine (Ethernet, keyboard, etc.). I cannot provide an easy test >> case >> > yet as besides the framework some expensive gyroscope and the 16550A >> > driver are involved. >> >> I observed a similar issue when xnpod_stop_timer was called when >> shutting down the posix skin. I assumed that the problem was that >> xnpod_shutdown already called xnpod_stop_timer, so xnpod_stop_timer (and >> in particular xnarch_stop_timer) ended up being called twice. >> > > Err, sorry. Forget about my previous reply: xnarch_stop_timer is _not_ > protected by the XNTIMED flag, but only the last part of the > housekeeping chores performed upon stopping the systimer are. IOW, this > is a latent bug, and xnpod_stop_timer should be fixed. > Commit 884 should do that. -- Philippe.