RE: bug seen with dynticks from CONFIG_HARDIRQS_SW_RESEND

[Thomas Gleixner <tglx@linutronix.de>]

On Thu, 2007-05-17 at 15:14 -0500, Woodruff, Richard wrote:
> > which code is disabling / enabling the timer interrupt ?
> 
> - No one in this case is calling enable_irq(#timer). The failure is
> triggered from a non-tick-related enable_irq(#x). The function
> handle_IRQ_event() always calls handle_dynamic_tick(). Thus every real
> interrupt or fake interrupt though resend_irq will touch the timer code
> paths.
> 
> To better describe:
>   -0- Users space does an ioctl to driver
>   -1- This driver calls enable_irq(#x)
>   -2- This triggers a check_irq_resend()
>   -3- This causes a tasklet schedule of the resend_tasklet for #x
>   -4- This driver later does a spin_unlock_bh
>   -5- This triggers a check for softirq/tasklets
>   -6- The resend_tasklet is run and calls desc->handle_irq
>   -7- This calls handle_level_irq
>   -8- This calls handle_IRQ_event
>   -9- This first calls handle_dynamic_tick

This is the original ARM dyntick stuff, right ?

The dyntick support on your architecture is broken. Why does it fiddle
with the timer, when the system is not idle ?

This stuff should go away ASAP. A lot of ARMs are already converted to
clock events are using the generic NOHZ implementation, which does not
have those problems at all.

	tglx