From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Thu, 31 Mar 2016 12:03:08 +0200 From: Gilles Chanteperdrix Message-ID: <20160331100308.GA4744@hermes.click-hack.org> References: <56F96800.6090301@mperpetuo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <56F96800.6090301@mperpetuo.com> Subject: Re: [Xenomai] arm64: spurious timer tick List-Id: Discussions about the Xenomai project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Dmitriy Cherkasov Cc: "xenomai@xenomai.org" On Mon, Mar 28, 2016 at 10:21:04AM -0700, Dmitriy Cherkasov wrote: > Hello, > > I have noticed that when Xenomai is running on an arm64 platform that uses > the arm architected timer, a spurious timer tick can occur. I believe all arm64 platforms so far use the architected timers. It would seem not all of them have spurious timer ticks, though. > > Here is a patch to observe it: > > diff --git a/drivers/clocksource/arm_arch_timer.c > b/drivers/clocksource/arm_arch_timer.c > index 51230ee7..4a91ce6 100644 > --- a/drivers/clocksource/arm_arch_timer.c > +++ b/drivers/clocksource/arm_arch_timer.c > @@ -148,6 +148,10 @@ static int arch_timer_ack(const int access, struct > clock_event_device *evt) > arch_timer_reg_write(access, ARCH_TIMER_REG_CTRL, ctrl, evt); > return 1; > } > + > + printk("spurious timer tick\n"); > + dump_stack(); > + > return 0; > } > > > On the 410c, it is sufficient to apply this patch and run switchtest - the > issue occurs quite frequently - about every 15 seconds on my board. > > Below is a stack trace that I get with the above patch: > > [57283.366174] [] dump_backtrace+0x0/0x12c > [57283.368974] [] show_stack+0x10/0x1c > [57283.373904] [] dump_stack+0x88/0xd8 > [57283.378910] [] arch_timer_ack+0x110/0x12c > [57283.383917] [] arch_itimer_ack_virt+0x20/0x2c > [57283.389281] [] __ipipe_ack_hrtimer_irq+0x2c/0x60 > [57283.395194] [] __ipipe_dispatch_irq+0x88/0x1e4 > [57283.401414] [] __ipipe_grab_irq+0x78/0x90 > [57283.484836] [] gic_handle_irq+0x38/0x7c > [57283.570645] [] el1_irq+0x68/0x94 > [57283.578846] [] program_htick_shot+0xdc/0xfc > [57283.583516] [] clockevents_program_event+0x78/0x104 > [57283.589336] [] tick_program_event+0x28/0x34 > [57283.595797] [] __remove_hrtimer+0xf4/0x100 > [57283.601567] [] __hrtimer_start_range_ns+0x1ec/0x344 > [57283.607364] [] hrtimer_start+0x14/0x20 > [57283.613726] [] __tick_nohz_idle_enter+0x328/0x3e8 > [57283.619182] [] tick_nohz_idle_enter+0x3c/0x7c > [57283.625212] [] cpu_startup_entry+0x44/0x290 > [57283.631157] [] rest_init+0xc0/0xd0 > [57283.637080] [] start_kernel+0x3c4/0x3dc > > Any help figuring out why this is happening would be much appreciated. >>From that stack trace, it would appear it happens when the timer next_event callback is called while the timer has not ticked yet, so, when reprogramming the timer outside the timer interrupt. I think you can try and see if the mainline kernel has the same problem in the same conditions, and if it does, bring the question to the linux arm kernel mailing list, where people from ARM will be able to answer you. -- Gilles. https://click-hack.org