Level interrupts need to be ack'd in the unmask handler, as in powerpc.
Among other issues, this bug causes the system clock to appear to run at
double-speed.
Signed-off-by: Steven J. Magnani <[email protected]>
---
diff -uprN a/arch/microblaze/kernel/intc.c b/arch/microblaze/kernel/intc.c
--- a/arch/microblaze/kernel/intc.c 2009-06-02 15:26:28.000000000 -0500
+++ b/arch/microblaze/kernel/intc.c 2009-06-02 15:27:39.000000000 -0500
@@ -41,8 +41,16 @@ unsigned int nr_irq;
static void intc_enable_or_unmask(unsigned int irq)
{
+ unsigned long mask = 1 << irq;
pr_debug("enable_or_unmask: %d\n", irq);
- out_be32(INTC_BASE + SIE, 1 << irq);
+ out_be32(INTC_BASE + SIE, mask);
+
+ /* ack level irqs because they can't be acked during
+ * ack function since the handle_level_irq function
+ * acks the irq before calling the interrupt handler
+ */
+ if (irq_desc[irq].status & IRQ_LEVEL)
+ out_be32(INTC_BASE + IAR, mask);
}
static void intc_disable_or_mask(unsigned int irq)
Hi Steve,
[email protected] wrote:
> Level interrupts need to be ack'd in the unmask handler, as in powerpc.
> Among other issues, this bug causes the system clock to appear to run at
> double-speed.
Can you send me any step-by-step manual how to demonstrate me this
fault? If system clock runs at double-speed, then I should be able able
to see that time is two times faster. Or do you mean different behavior?
Thanks,
Michal
>
> Signed-off-by: Steven J. Magnani <[email protected]>
> ---
> diff -uprN a/arch/microblaze/kernel/intc.c b/arch/microblaze/kernel/intc.c
> --- a/arch/microblaze/kernel/intc.c 2009-06-02 15:26:28.000000000 -0500
> +++ b/arch/microblaze/kernel/intc.c 2009-06-02 15:27:39.000000000 -0500
> @@ -41,8 +41,16 @@ unsigned int nr_irq;
>
> static void intc_enable_or_unmask(unsigned int irq)
> {
> + unsigned long mask = 1 << irq;
> pr_debug("enable_or_unmask: %d\n", irq);
> - out_be32(INTC_BASE + SIE, 1 << irq);
> + out_be32(INTC_BASE + SIE, mask);
> +
> + /* ack level irqs because they can't be acked during
> + * ack function since the handle_level_irq function
> + * acks the irq before calling the interrupt handler
> + */
> + if (irq_desc[irq].status & IRQ_LEVEL)
> + out_be32(INTC_BASE + IAR, mask);
> }
>
> static void intc_disable_or_mask(unsigned int irq)
>
> --
> 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/
--
Michal Simek, Ing. (M.Eng)
w: http://www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel 2.6 Microblaze Linux - http://www.monstr.eu/fdt/
Microblaze U-BOOT custodian
On Fri, 2009-11-20 at 12:07 +0100, Michal Simek wrote:
> Hi Steve,
>
> [email protected] wrote:
> > Level interrupts need to be ack'd in the unmask handler, as in powerpc.
> > Among other issues, this bug causes the system clock to appear to run at
> > double-speed.
>
> Can you send me any step-by-step manual how to demonstrate me this
> fault? If system clock runs at double-speed, then I should be able able
> to see that time is two times faster. Or do you mean different behavior?
Unless there's a way to read jiffies_64 in userspace, the easiest way I
know of is to use the debugger. Stop the kernel soon after you boot it,
and read jiffies_64. Continue execution for some known amount of
wall-clock time, then stop the kernel again and recheck jiffies_64.
Without the patch, the number of elapsed jiffies is twice what you'd
expect based on HZ.
>
> Thanks,
> Michal
Regards,
------------------------------------------------------------------------
Steven J. Magnani "I claim this network for MARS!
http://www.digidescorp.com Earthling, return my space modulator!"
#include <standard.disclaimer>
Steven J. Magnani wrote:
> On Fri, 2009-11-20 at 12:07 +0100, Michal Simek wrote:
>> Hi Steve,
>>
>> [email protected] wrote:
>>> Level interrupts need to be ack'd in the unmask handler, as in powerpc.
>>> Among other issues, this bug causes the system clock to appear to run at
>>> double-speed.
>> Can you send me any step-by-step manual how to demonstrate me this
>> fault? If system clock runs at double-speed, then I should be able able
>> to see that time is two times faster. Or do you mean different behavior?
>
> Unless there's a way to read jiffies_64 in userspace, the easiest way I
> know of is to use the debugger. Stop the kernel soon after you boot it,
> and read jiffies_64. Continue execution for some known amount of
> wall-clock time, then stop the kernel again and recheck jiffies_64.
> Without the patch, the number of elapsed jiffies is twice what you'd
> expect based on HZ.
yes, I saw that behavior. Just thinking what caused that jiffies was two
times faster.
But anyway. I added this patch to next branch.
Thanks,
Michal
>
>> Thanks,
>> Michal
>
> Regards,
> ------------------------------------------------------------------------
> Steven J. Magnani "I claim this network for MARS!
> http://www.digidescorp.com Earthling, return my space modulator!"
>
> #include <standard.disclaimer>
>
>
>
> --
> 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/
--
Michal Simek, Ing. (M.Eng)
PetaLogix - Linux Solutions for a Reconfigurable World
w: http://www.petalogix.com p: +61-7-30090663,+42-0-721842854 f: +61-7-30090663