On Thu, 2007-05-17 at 17:24 -0500, Woodruff, Richard wrote:
> > This is the original ARM dyntick stuff, right ?
>
> Yes this is a version is not using clocksource.
>
> > The dyntick support on your architecture is broken. Why does it fiddle
> > with the timer, when the system is not idle ?
>
> I
> This is the original ARM dyntick stuff, right ?
Yes this is a version is not using clocksource.
> The dyntick support on your architecture is broken. Why does it fiddle
> with the timer, when the system is not idle ?
I can't yet run the test sequence on the latest kernel so I'll have to
wait t
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
> On Wed, 2007-05-16 at 18:20 -0500, Woodruff, Richard wrote:
> > The crashes were because the frame pointer per_cpuirq_regs value
was
> > 0. That code does a user_mode(get_irq_regs()). Currently regs is
set
> > only upon real hardware entry on an irq.
> >
> > The crash path shows resend_irqs
On Wed, 2007-05-16 at 18:20 -0500, Woodruff, Richard wrote:
> The crashes were because the frame pointer per_cpuirq_regs value was
> 0. That code does a user_mode(get_irq_regs()). Currently regs is set
> only upon real hardware entry on an irq.
>
> The crash path shows resend_irqs() could be
5 matches
Mail list logo
