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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
