From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <4DC2C411.60109@domain.hid> Date: Thu, 05 May 2011 17:36:49 +0200 From: Gilles Chanteperdrix MIME-Version: 1.0 References: <4DC2962B.9060802@domain.hid> <4DC299F2.40700@domain.hid> <4DC2A315.8030707@domain.hid> <4DC2ADE1.9000301@domain.hid> <4DC2B06B.9020303@domain.hid> <4DC2B75C.8030503@domain.hid> <4DC2C10C.9080102@domain.hid> In-Reply-To: <4DC2C10C.9080102@domain.hid> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [Adeos-main] mini2440: ipipe kernel stuck in idle loop after xenomai init List-Id: General discussion about Adeos List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alexey Galakhov Cc: adeos-main@gna.org On 05/05/2011 05:23 PM, Alexey Galakhov wrote: > On 05/05/2011 08:42 PM, Gilles Chanteperdrix wrote: >> On 05/05/2011 04:12 PM, Alexey Galakhov wrote: >>> On 05/05/2011 08:02 PM, Gilles Chanteperdrix wrote: >>>> On 05/05/2011 03:16 PM, Alexey Galakhov wrote: >>>>> May it be caused by the following code from plat-samsung/time.c ? >>>>> >>>>> static inline void set_dec(unsigned long reload) >>>>> { >>>>> __raw_writel(reload, S3C2410_TCNTB(4)); /* <-------- In fact, >>>>> TCNT is 16-bit, so what if reload > 0xffff and reload & 0xffff == 0 ??? */ >>>> Try adding: >>>> >>>> if (reload > 0xffff) >>>> reload = 0xffff; >>>> >>>> before the raw_writel >>> No effect. It may make sense but does not fix this bug. >> It may also happen that the timer has a lower limit, when the reload >> parameter is below this limit, you shoud call ipipe_trigger_irq, as >> explained in the porting guide. > Seems to be not the case but tried it anyway (guessed lower limit > 0x00ff), no effect. Also tried to add printk to __ipipe_mach_set_dec, > got the following: This is probably the same issue as I had on AT91. Please try disabling the NO_HZ configuration option. -- Gilles.