From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <4370C966.3030903@domain.hid> Date: Tue, 08 Nov 2005 16:51:02 +0100 From: Philippe Gerum MIME-Version: 1.0 Subject: Re: [Xenomai-core] [BUG] scheduling order of dying shadow threads References: <4370641D.7010906@domain.hid> In-Reply-To: <4370641D.7010906@domain.hid> Content-Type: text/plain; charset=ISO-8859-15; 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: Jan Kiszka Cc: xenomai-core Jan Kiszka wrote: > Hi Philippe, > > I think this one is for you: ;) > > Sebastian got almost mad with his CAN driver while tracing a strange > scheduling behaviour during shadow thread deletion for several days(!) - > and I was right on the way to follow him yesterday evening. Attached is > a simplified demonstration of the effect, consisting of a RTDM driver > and both a kernel and user space application to trigger it. > I've spotted the issue in nucleus/shadow.c. Basically, the root thread priority boost was leaking to a non-shadow thread due to a missing priority reset in the lostage APC handler, whilst a shadow was in the process of relaxing. Really funky bug, thanks! :o> Fixed in the repo hopefully for good. The scheduling sequence is now correct with your demo app on my box. -- Philippe.