Re: ARM: OMAP3: Fix get_irqnr_and_base to clear spurious interrupt bits

Re: ARM: OMAP3: Fix get_irqnr_and_base to clear spurious interrupt bits

[Rick Bronson]

Tony,

> Well we should let the generic irq handler to do the logging.. But I
> guess nothing will happen if adm_do_IRQ() does not get called.
> 
> We could have a dummy handler for some invented higher number that would
> capture the spurious interrupts I guess.
> 
> BTW, ideally we would do the ldr conditionally rather than every time,
> I guess that's the idea with the old way of doing things.

  Well, actually the ldr (I assume you mean this one):

		ldrne	\irqnr, [\base, #INTCPS_SIR_IRQ_OFFSET]

  was being done everytime, since presumably, at least one of the
"pending" bits would be set otherwise how would we get to this
interrupt?  Which bring up a point - why bother even checking the
pending bits at all?   Just grab the irqnr, check for spurious and
exit.

  Rick

Re: ARM: OMAP3: Fix get_irqnr_and_base to clear spurious interrupt bits

[Tony Lindgren]

* Rick Bronson <rick@efn.org> [081023 11:13]:
> Tony,
> 
> > Well we should let the generic irq handler to do the logging.. But I
> > guess nothing will happen if adm_do_IRQ() does not get called.
> > 
> > We could have a dummy handler for some invented higher number that would
> > capture the spurious interrupts I guess.
> > 
> > BTW, ideally we would do the ldr conditionally rather than every time,
> > I guess that's the idea with the old way of doing things.
> 
>   Well, actually the ldr (I assume you mean this one):
> 
> 		ldrne	\irqnr, [\base, #INTCPS_SIR_IRQ_OFFSET]
> 
>   was being done everytime, since presumably, at least one of the
> "pending" bits would be set otherwise how would we get to this
> interrupt?  Which bring up a point - why bother even checking the
> pending bits at all?   Just grab the irqnr, check for spurious and
> exit.

Yeah that would be nice.

Tony

Re: ARM: OMAP3: Fix get_irqnr_and_base to clear spurious interrupt bits

[Rick Bronson]

Tony,

  The last patch I posted didn't work quite right.  It seems we do
actually come into this macro with none of the pending bits set.
Presumably, because the interrupt hasn't been ack'd yet.  Anyway, I've
tested this patch and I think it's golden.  It ack's spurious
interrupts and lets the user know that one has occured by setting irq
to NR_IRQS then arch/arm/kernel/irq.c will use bad_irq_desc when it
processes the interrupt.  This message get's printed upon spurious
interrupt:

->handle_irq():  c0073448, handle_bad_irq+0x0/0x228                             
->chip(): 00000000, 0x0                                                         
->action(): 00000000                                                            

  The only bad thing is that it doesn't notify the user WHICH spurious
interrupt happened.  Any ideas on solving that?

  Rick

--- linux-omap-2.6/arch/arm/plat-omap/include/mach/entry-macro.S.git	2008-10-22 20:01:33.000000000 -0700
+++ linux-omap-2.6/arch/arm/plat-omap/include/mach/entry-macro.S	2008-10-27 08:41:08.000000000 -0700
@@ -66,7 +66,11 @@
 #endif
 
 #define INTCPS_SIR_IRQ_OFFSET	0x0040		/* Active interrupt offset */
-#define	ACTIVEIRQ_MASK		0x7f		/* Active interrupt bits */
+#define INTCPS_CONTROL		0x0048		/* new interrupt agreement bits */
+#define INTCPS_PENDING_IRQ_1	0x0098		/* IRQ pending reg 1 */
+#define INTCPS_PENDING_IRQ_2	0x00b8		/* IRQ pending reg 2 */
+#define INTCPS_PENDING_IRQ_3	0x00d8		/* IRQ pending reg 3 */
+#define INTCPS_CONTROL_NEWIRQAGR 0x0001		/* Reset IRQ output and enable new IRQ generation */
 
 		.macro	disable_fiq
 		.endm
@@ -79,18 +83,19 @@
 
 		.macro	get_irqnr_and_base, irqnr, irqstat, base, tmp
 		ldr	\base, =OMAP2_VA_IC_BASE
-		ldr	\irqnr, [\base, #0x98] /* IRQ pending reg 1 */
-		cmp	\irqnr, #0x0
-		bne	2222f
-		ldr	\irqnr, [\base, #0xb8] /* IRQ pending reg 2 */
-		cmp	\irqnr, #0x0
-		bne	2222f
-		ldr	\irqnr, [\base, #0xd8] /* IRQ pending reg 3 */
-		cmp	\irqnr, #0x0
+		ldr	\irqstat, [\base, #INTCPS_PENDING_IRQ_1] /* IRQ pending reg 1 */
+		ldr	\tmp, [\base, #INTCPS_PENDING_IRQ_2] /* IRQ pending reg 2 */
+		orr	\irqstat, \irqstat, \tmp  /* or them all together */
+		ldr	\tmp, [\base, #INTCPS_PENDING_IRQ_3] /* IRQ pending reg 3 */
+		orrs	\irqstat, \irqstat, \tmp  /* set condition code Z if interrupt */
+		beq	2222f  /* if there are no interrupt bits set, leave with Z=1 */
+		ldr	\irqnr, [\base, #INTCPS_SIR_IRQ_OFFSET]
+		adds	\tmp, \irqnr, #1 /* change from zero based to 1 based so we clear Z */
+		bpl	2222f  /* if no spurious interrupt */
+		mov	\tmp, #INTCPS_CONTROL_NEWIRQAGR /* Ack the spurious irq	*/
+		str	\tmp, [\base, #INTCPS_CONTROL]
+		movw	\irqnr, #NR_IRQS /* set to NR_IRQS so that bad_irq_desc() get's called */
 2222:
-		ldrne	\irqnr, [\base, #INTCPS_SIR_IRQ_OFFSET]
-		and	\irqnr, \irqnr, #ACTIVEIRQ_MASK /* Clear spurious bits */
-
 		.endm
 
 		.macro	irq_prio_table

Re: ARM: OMAP3: Fix get_irqnr_and_base to clear spurious interrupt bits

[Tony Lindgren]

* Rick Bronson <rick@efn.org> [081028 09:19]:
> Tony,
> 
>   The last patch I posted didn't work quite right.  It seems we do
> actually come into this macro with none of the pending bits set.
> Presumably, because the interrupt hasn't been ack'd yet.  Anyway, I've
> tested this patch and I think it's golden.  It ack's spurious
> interrupts and lets the user know that one has occured by setting irq
> to NR_IRQS then arch/arm/kernel/irq.c will use bad_irq_desc when it
> processes the interrupt.  This message get's printed upon spurious
> interrupt:
> 
> ->handle_irq():  c0073448, handle_bad_irq+0x0/0x228                             
> ->chip(): 00000000, 0x0                                                         
> ->action(): 00000000                                                            

Heh, so back to checking the pending registers again :)

>   The only bad thing is that it doesn't notify the user WHICH spurious
> interrupt happened.  Any ideas on solving that?

Well considering that we're now only getting them rarely, maybe we
should just keep the irqnr as it is and handle it in the higher level?

Otherwise we won't know if it's the device causing the spurious interrupts
or the write posting on the L4 bus.

Anyways, I guess the real issue we have now is why write posts to L4
bus cause the problem.

Regards,

Tony


> 
>   Rick
> 
> --- linux-omap-2.6/arch/arm/plat-omap/include/mach/entry-macro.S.git	2008-10-22 20:01:33.000000000 -0700
> +++ linux-omap-2.6/arch/arm/plat-omap/include/mach/entry-macro.S	2008-10-27 08:41:08.000000000 -0700
> @@ -66,7 +66,11 @@
>  #endif
>  
>  #define INTCPS_SIR_IRQ_OFFSET	0x0040		/* Active interrupt offset */
> -#define	ACTIVEIRQ_MASK		0x7f		/* Active interrupt bits */
> +#define INTCPS_CONTROL		0x0048		/* new interrupt agreement bits */
> +#define INTCPS_PENDING_IRQ_1	0x0098		/* IRQ pending reg 1 */
> +#define INTCPS_PENDING_IRQ_2	0x00b8		/* IRQ pending reg 2 */
> +#define INTCPS_PENDING_IRQ_3	0x00d8		/* IRQ pending reg 3 */
> +#define INTCPS_CONTROL_NEWIRQAGR 0x0001		/* Reset IRQ output and enable new IRQ generation */
>  
>  		.macro	disable_fiq
>  		.endm
> @@ -79,18 +83,19 @@
>  
>  		.macro	get_irqnr_and_base, irqnr, irqstat, base, tmp
>  		ldr	\base, =OMAP2_VA_IC_BASE
> -		ldr	\irqnr, [\base, #0x98] /* IRQ pending reg 1 */
> -		cmp	\irqnr, #0x0
> -		bne	2222f
> -		ldr	\irqnr, [\base, #0xb8] /* IRQ pending reg 2 */
> -		cmp	\irqnr, #0x0
> -		bne	2222f
> -		ldr	\irqnr, [\base, #0xd8] /* IRQ pending reg 3 */
> -		cmp	\irqnr, #0x0
> +		ldr	\irqstat, [\base, #INTCPS_PENDING_IRQ_1] /* IRQ pending reg 1 */
> +		ldr	\tmp, [\base, #INTCPS_PENDING_IRQ_2] /* IRQ pending reg 2 */
> +		orr	\irqstat, \irqstat, \tmp  /* or them all together */
> +		ldr	\tmp, [\base, #INTCPS_PENDING_IRQ_3] /* IRQ pending reg 3 */
> +		orrs	\irqstat, \irqstat, \tmp  /* set condition code Z if interrupt */
> +		beq	2222f  /* if there are no interrupt bits set, leave with Z=1 */
> +		ldr	\irqnr, [\base, #INTCPS_SIR_IRQ_OFFSET]
> +		adds	\tmp, \irqnr, #1 /* change from zero based to 1 based so we clear Z */
> +		bpl	2222f  /* if no spurious interrupt */
> +		mov	\tmp, #INTCPS_CONTROL_NEWIRQAGR /* Ack the spurious irq	*/
> +		str	\tmp, [\base, #INTCPS_CONTROL]
> +		movw	\irqnr, #NR_IRQS /* set to NR_IRQS so that bad_irq_desc() get's called */
>  2222:
> -		ldrne	\irqnr, [\base, #INTCPS_SIR_IRQ_OFFSET]
> -		and	\irqnr, \irqnr, #ACTIVEIRQ_MASK /* Clear spurious bits */
> -
>  		.endm
>  
>  		.macro	irq_prio_table
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: ARM: OMAP3: Fix get_irqnr_and_base to clear spurious interrupt bits

[Tony Lindgren]

* Rick Bronson <rick@efn.org> [081028 09:19]:
> Tony,
> 
>   The last patch I posted didn't work quite right.  It seems we do
> actually come into this macro with none of the pending bits set.
> Presumably, because the interrupt hasn't been ack'd yet.  Anyway, I've
> tested this patch and I think it's golden.  It ack's spurious
> interrupts and lets the user know that one has occured by setting irq
> to NR_IRQS then arch/arm/kernel/irq.c will use bad_irq_desc when it
> processes the interrupt.  This message get's printed upon spurious
> interrupt:
> 
> ->handle_irq():  c0073448, handle_bad_irq+0x0/0x228                             
> ->chip(): 00000000, 0x0                                                         
> ->action(): 00000000                                                            
> 
>   The only bad thing is that it doesn't notify the user WHICH spurious
> interrupt happened.  Any ideas on solving that?

Hey can you try out the series I just posted? I think I figured out
a way to print out the interrupt handler that actually causes the
spurious interrupt. So it should be easy to fix it now where needed :)

If you have the automated reboot test still available, it might be easy
to fix the previous irq 25 and 37 issues.

Tony

> 
>   Rick
> 
> --- linux-omap-2.6/arch/arm/plat-omap/include/mach/entry-macro.S.git	2008-10-22 20:01:33.000000000 -0700
> +++ linux-omap-2.6/arch/arm/plat-omap/include/mach/entry-macro.S	2008-10-27 08:41:08.000000000 -0700
> @@ -66,7 +66,11 @@
>  #endif
>  
>  #define INTCPS_SIR_IRQ_OFFSET	0x0040		/* Active interrupt offset */
> -#define	ACTIVEIRQ_MASK		0x7f		/* Active interrupt bits */
> +#define INTCPS_CONTROL		0x0048		/* new interrupt agreement bits */
> +#define INTCPS_PENDING_IRQ_1	0x0098		/* IRQ pending reg 1 */
> +#define INTCPS_PENDING_IRQ_2	0x00b8		/* IRQ pending reg 2 */
> +#define INTCPS_PENDING_IRQ_3	0x00d8		/* IRQ pending reg 3 */
> +#define INTCPS_CONTROL_NEWIRQAGR 0x0001		/* Reset IRQ output and enable new IRQ generation */
>  
>  		.macro	disable_fiq
>  		.endm
> @@ -79,18 +83,19 @@
>  
>  		.macro	get_irqnr_and_base, irqnr, irqstat, base, tmp
>  		ldr	\base, =OMAP2_VA_IC_BASE
> -		ldr	\irqnr, [\base, #0x98] /* IRQ pending reg 1 */
> -		cmp	\irqnr, #0x0
> -		bne	2222f
> -		ldr	\irqnr, [\base, #0xb8] /* IRQ pending reg 2 */
> -		cmp	\irqnr, #0x0
> -		bne	2222f
> -		ldr	\irqnr, [\base, #0xd8] /* IRQ pending reg 3 */
> -		cmp	\irqnr, #0x0
> +		ldr	\irqstat, [\base, #INTCPS_PENDING_IRQ_1] /* IRQ pending reg 1 */
> +		ldr	\tmp, [\base, #INTCPS_PENDING_IRQ_2] /* IRQ pending reg 2 */
> +		orr	\irqstat, \irqstat, \tmp  /* or them all together */
> +		ldr	\tmp, [\base, #INTCPS_PENDING_IRQ_3] /* IRQ pending reg 3 */
> +		orrs	\irqstat, \irqstat, \tmp  /* set condition code Z if interrupt */
> +		beq	2222f  /* if there are no interrupt bits set, leave with Z=1 */
> +		ldr	\irqnr, [\base, #INTCPS_SIR_IRQ_OFFSET]
> +		adds	\tmp, \irqnr, #1 /* change from zero based to 1 based so we clear Z */
> +		bpl	2222f  /* if no spurious interrupt */
> +		mov	\tmp, #INTCPS_CONTROL_NEWIRQAGR /* Ack the spurious irq	*/
> +		str	\tmp, [\base, #INTCPS_CONTROL]
> +		movw	\irqnr, #NR_IRQS /* set to NR_IRQS so that bad_irq_desc() get's called */
>  2222:
> -		ldrne	\irqnr, [\base, #INTCPS_SIR_IRQ_OFFSET]
> -		and	\irqnr, \irqnr, #ACTIVEIRQ_MASK /* Clear spurious bits */
> -
>  		.endm
>  
>  		.macro	irq_prio_table
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: ARM: OMAP3: Fix get_irqnr_and_base to clear spurious interrupt bits

[Rick Bronson]

Tony,

  How does this look?

  If we set irq to NR_IRQS then arch/arm/kernel/irq.c will use
bad_irq_desc when it processes the interrupt.  NOTE: I haven't tested
this yet.

  Rick


--- linux-omap-2.6/arch/arm/plat-omap/include/mach/entry-macro.S.git	2008-10-22 20:01:33.000000000 -0700
+++ linux-omap-2.6/arch/arm/plat-omap/include/mach/entry-macro.S	2008-10-23 21:12:29.000000000 -0700
@@ -66,7 +66,8 @@
 #endif
 
 #define INTCPS_SIR_IRQ_OFFSET	0x0040		/* Active interrupt offset */
-#define	ACTIVEIRQ_MASK		0x7f		/* Active interrupt bits */
+#define INTCPS_CONTROL		0x0048		/* new interrupt agreement bits */
+#define INTCPS_CONTROL_NEWIRQAGR 0x0001		/* Reset IRQ output and enable new IRQ generation */
 
 		.macro	disable_fiq
 		.endm
@@ -79,18 +80,13 @@
 
 		.macro	get_irqnr_and_base, irqnr, irqstat, base, tmp
 		ldr	\base, =OMAP2_VA_IC_BASE
-		ldr	\irqnr, [\base, #0x98] /* IRQ pending reg 1 */
-		cmp	\irqnr, #0x0
-		bne	2222f
-		ldr	\irqnr, [\base, #0xb8] /* IRQ pending reg 2 */
-		cmp	\irqnr, #0x0
-		bne	2222f
-		ldr	\irqnr, [\base, #0xd8] /* IRQ pending reg 3 */
-		cmp	\irqnr, #0x0
+		ldr	\irqnr, [\base, #INTCPS_SIR_IRQ_OFFSET]  /* NOTE: range is 0-0x5f and 0ffffff80 to 0xffffffdf */
+		adds	\tmp, \irqnr, #1 /* change from zero based to 1 based so we clear Z */
+		bpl	2222f  /* if no spurious interrupt */
+		mov	\tmp, #INTCPS_CONTROL_NEWIRQAGR /* Ack the spurious irq */
+		str	\tmp, [\base, #INTCPS_CONTROL]
+		movw	\irqnr, #NR_IRQS /* set to NR_IRQS so that bad_irq_desc() get's called */
 2222:
-		ldrne	\irqnr, [\base, #INTCPS_SIR_IRQ_OFFSET]
-		and	\irqnr, \irqnr, #ACTIVEIRQ_MASK /* Clear spurious bits */
-
 		.endm
 
 		.macro	irq_prio_table

Re: ARM: OMAP3: Fix get_irqnr_and_base to clear spurious interrupt bits

[Rick Bronson]

Tony,

  I checked out some other ARM spurious interrupt handling and it
seems that they ack the interrupt but left the macro with the Z bit
set which means that asm_do_IRQ() does not get called.  Seems to me we
should do the same, see the patch below.  Although, ideally, we should
be logging these.  Is there a mechanism for doing this?

> Are these defines above still needed?

  Yes.

  BTW, I haven't checked this patch so don't do anything with it, just
comment on it ;-)

 Rick

--- linux-omap-2.6/arch/arm/plat-omap/include/mach/entry-macro.S.git	2008-10-22 20:01:33.000000000 -0700
+++ linux-omap-2.6/arch/arm/plat-omap/include/mach/entry-macro.S	2008-10-23 10:25:57.000000000 -0700
@@ -66,7 +66,11 @@
 #endif
 
 #define INTCPS_SIR_IRQ_OFFSET	0x0040		/* Active interrupt offset */
-#define	ACTIVEIRQ_MASK		0x7f		/* Active interrupt bits */
+#define INTCPS_CONTROL		0x0048		/* new interrupt agreement bits offset */
+#define INTCPS_CONTROL_NEWIRQAGR 0x0001		/* Reset IRQ output and enable new IRQ generation */
+#define INTCPS_PENDING_IRQ_1	0x0098		/* IRQ pending reg 1 */
+#define INTCPS_PENDING_IRQ_2	0x00b8		/* IRQ pending reg 2 */
+#define INTCPS_PENDING_IRQ_3	0x00d8		/* IRQ pending reg 3 */
 
 		.macro	disable_fiq
 		.endm
@@ -79,18 +83,18 @@
 
 		.macro	get_irqnr_and_base, irqnr, irqstat, base, tmp
 		ldr	\base, =OMAP2_VA_IC_BASE
-		ldr	\irqnr, [\base, #0x98] /* IRQ pending reg 1 */
-		cmp	\irqnr, #0x0
-		bne	2222f
-		ldr	\irqnr, [\base, #0xb8] /* IRQ pending reg 2 */
-		cmp	\irqnr, #0x0
-		bne	2222f
-		ldr	\irqnr, [\base, #0xd8] /* IRQ pending reg 3 */
-		cmp	\irqnr, #0x0
-2222:
-		ldrne	\irqnr, [\base, #INTCPS_SIR_IRQ_OFFSET]
-		and	\irqnr, \irqnr, #ACTIVEIRQ_MASK /* Clear spurious bits */
-
+		ldr	\irqnr, [\base, #INTCPS_SIR_IRQ_OFFSET]
+		mvn	\tmp, \irqnr  /* flip MSBit */
+		bics	\tmp, #0x80000000  /* test MSBit */
+		moveq	\tmp, #INTCPS_CONTROL_NEWIRQAGR /* Ack the spurious irq */
+		streq	\tmp, [\base, #INTCPS_CONTROL]
+		beq	2223f  /* if we got a spurious interrupt, ignore it */
+		ldr	\irqstat, [\base, #INTCPS_PENDING_IRQ_1] /* IRQ pending reg 1 */
+		ldr	\tmp, [\base, #INTCPS_PENDING_IRQ_2] /* IRQ pending reg 2 */
+		orr	\irqstat, \irqstat, \tmp  /* or them all together */
+		ldr	\tmp, [\base, #INTCPS_PENDING_IRQ_3] /* IRQ pending reg 3 */
+		orrs	\irqstat, \irqstat, \tmp  /* clear condition code Z if interrupt */
+2223:
 		.endm
 
 		.macro	irq_prio_table

Re: ARM: OMAP3: Fix get_irqnr_and_base to clear spurious interrupt bits

[Rick Bronson]

Tony,

  Here is the patch against the latest git.  I'm a little concerned
about masking the interrupt number so that the spurious bit are
ignored.  Do you really want to turn a spurious interrupt into a
normal (good) interrupt?

> Also, AFAIK we don't have infinitely repeating irqs any longer, it's
> just an occasional single spurious interrupt.

  That's correct.  And those disappeared when I applied the S-O patch.
Without the S-O patch I was seeing one spurious interrupt in about 15
reboots, after the patch I got zero in 350 reboots.

  Rick

--- linux-omap-2.6/arch/arm/plat-omap/include/mach/entry-macro.S.git	2008-10-22 20:01:33.000000000 -0700
+++ linux-omap-2.6/arch/arm/plat-omap/include/mach/entry-macro.S	2008-10-22 20:11:26.000000000 -0700
@@ -67,6 +67,10 @@
 
 #define INTCPS_SIR_IRQ_OFFSET	0x0040		/* Active interrupt offset */
 #define	ACTIVEIRQ_MASK		0x7f		/* Active interrupt bits */
+#define INTCPS_CONTROL		0x0048		/* new interrupt agreement bits */
+#define INTCPS_PENDING_IRQ_1	0x0098		/* IRQ pending reg 1 */
+#define INTCPS_PENDING_IRQ_2	0x00b8		/* IRQ pending reg 2 */
+#define INTCPS_PENDING_IRQ_3	0x00d8		/* IRQ pending reg 3 */
 
 		.macro	disable_fiq
 		.endm
@@ -79,18 +83,20 @@
 
 		.macro	get_irqnr_and_base, irqnr, irqstat, base, tmp
 		ldr	\base, =OMAP2_VA_IC_BASE
-		ldr	\irqnr, [\base, #0x98] /* IRQ pending reg 1 */
-		cmp	\irqnr, #0x0
-		bne	2222f
-		ldr	\irqnr, [\base, #0xb8] /* IRQ pending reg 2 */
-		cmp	\irqnr, #0x0
-		bne	2222f
-		ldr	\irqnr, [\base, #0xd8] /* IRQ pending reg 3 */
-		cmp	\irqnr, #0x0
-2222:
-		ldrne	\irqnr, [\base, #INTCPS_SIR_IRQ_OFFSET]
+		ldr	\irqnr, [\base, #INTCPS_SIR_IRQ_OFFSET]
+		cmp	\irqnr, #0  /* check for negative */
+		movmi	\tmp, #0x1 /* Ack the spurious irq, this lets it
+					* generate a bad irq error message,
+					* but prevents infinitely repeating
+					* irq.
+					*/
+		strmi	\tmp, [\base, #INTCPS_CONTROL]
 		and	\irqnr, \irqnr, #ACTIVEIRQ_MASK /* Clear spurious bits */
-

Re: ARM: OMAP3: Fix get_irqnr_and_base to clear spurious interrupt bits

[Tony Lindgren]

* Rick Bronson <rick@efn.org> [081022 20:30]:
> Tony,
> 
>   Here is the patch against the latest git.  I'm a little concerned
> about masking the interrupt number so that the spurious bit are
> ignored.  Do you really want to turn a spurious interrupt into a
> normal (good) interrupt?

No, but having the spurious data mess up the irqnr really confuses
things :)

> > Also, AFAIK we don't have infinitely repeating irqs any longer, it's
> > just an occasional single spurious interrupt.
> 
>   That's correct.  And those disappeared when I applied the S-O patch.
> Without the S-O patch I was seeing one spurious interrupt in about 15
> reboots, after the patch I got zero in 350 reboots.

Yeah so let's update the comment below.

>   Rick
> 
> --- linux-omap-2.6/arch/arm/plat-omap/include/mach/entry-macro.S.git	2008-10-22 20:01:33.000000000 -0700
> +++ linux-omap-2.6/arch/arm/plat-omap/include/mach/entry-macro.S	2008-10-22 20:11:26.000000000 -0700
> @@ -67,6 +67,10 @@
>  
>  #define INTCPS_SIR_IRQ_OFFSET	0x0040		/* Active interrupt offset */
>  #define	ACTIVEIRQ_MASK		0x7f		/* Active interrupt bits */
> +#define INTCPS_CONTROL		0x0048		/* new interrupt agreement bits */
> +#define INTCPS_PENDING_IRQ_1	0x0098		/* IRQ pending reg 1 */
> +#define INTCPS_PENDING_IRQ_2	0x00b8		/* IRQ pending reg 2 */
> +#define INTCPS_PENDING_IRQ_3	0x00d8		/* IRQ pending reg 3 */
>  
>  		.macro	disable_fiq
>  		.endm
> @@ -79,18 +83,20 @@

Are these defines above still needed?


>  
>  		.macro	get_irqnr_and_base, irqnr, irqstat, base, tmp
>  		ldr	\base, =OMAP2_VA_IC_BASE
> -		ldr	\irqnr, [\base, #0x98] /* IRQ pending reg 1 */
> -		cmp	\irqnr, #0x0
> -		bne	2222f
> -		ldr	\irqnr, [\base, #0xb8] /* IRQ pending reg 2 */
> -		cmp	\irqnr, #0x0
> -		bne	2222f
> -		ldr	\irqnr, [\base, #0xd8] /* IRQ pending reg 3 */
> -		cmp	\irqnr, #0x0
> -2222:
> -		ldrne	\irqnr, [\base, #INTCPS_SIR_IRQ_OFFSET]
> +		ldr	\irqnr, [\base, #INTCPS_SIR_IRQ_OFFSET]
> +		cmp	\irqnr, #0  /* check for negative */
> +		movmi	\tmp, #0x1 /* Ack the spurious irq, this lets it
> +					* generate a bad irq error message,
> +					* but prevents infinitely repeating
> +					* irq.
> +					*/
> +		strmi	\tmp, [\base, #INTCPS_CONTROL]
>  		and	\irqnr, \irqnr, #ACTIVEIRQ_MASK /* Clear spurious bits */

How about remove the comment for movmi above, and have just a comment
like /* ack spurious irq */ for the strmi instead?

Tony

Re: ARM: OMAP3: Fix get_irqnr_and_base to clear spurious interrupt bits

[Rick Bronson]

  Sorry if I'm late in the game for changes to entry-macro.S but I
worked on this code a bit ago and have been testing it.  What I have,
I think, is a little more straight forward.  Note that it doesn't have
the added mask for the spurious bits, but it does check for
spurious interrupts and handles them.

  Rick



--- linux-omap-2.6/arch/arm/plat-omap/include/mach/entry-macro.S.~1~	2008-10-16 13:33:31.000000000 -0700
+++ linux-omap-2.6/arch/arm/plat-omap/include/mach/entry-macro.S	2008-10-17 11:38:18.000000000 -0700
@@ -65,7 +65,11 @@
 #include <mach/omap34xx.h>
 #endif
 
-#define INTCPS_SIR_IRQ_OFFSET	0x0040		/* Active interrupt number */
+#define INTCPS_SIR_IRQ_OFFSET	0x0040	/* Active interrupt number */
+#define INTCPS_CONTROL		0x0048	/* new interrupt agreement bits */
+#define INTCPS_PENDING_IRQ_1	0x0098	/* IRQ pending reg 1 */
+#define INTCPS_PENDING_IRQ_2	0x00b8	/* IRQ pending reg 2 */
+#define INTCPS_PENDING_IRQ_3	0x00d8	/* IRQ pending reg 3 */
 
 		.macro	disable_fiq
 		.endm
@@ -78,17 +82,19 @@
 
 		.macro	get_irqnr_and_base, irqnr, irqstat, base, tmp
 		ldr	\base, =OMAP2_VA_IC_BASE
-		ldr	\irqnr, [\base, #0x98] /* IRQ pending reg 1 */
-		cmp	\irqnr, #0x0
-		bne	2222f
-		ldr	\irqnr, [\base, #0xb8] /* IRQ pending reg 2 */
-		cmp	\irqnr, #0x0
-		bne	2222f
-		ldr	\irqnr, [\base, #0xd8] /* IRQ pending reg 3 */
-		cmp	\irqnr, #0x0
-2222:
-		ldrne	\irqnr, [\base, #INTCPS_SIR_IRQ_OFFSET]
-
+		ldr	\irqnr, [\base, #INTCPS_SIR_IRQ_OFFSET]
+		cmp	\irqnr, #0  /* check for negative */
+		movmi	\tmp, #0x1 /* Ack the spurious irq, this lets it
+					* generate a bad irq error message,
+					* but prevents infinitely repeating
+					* irq.
+					*/
+		strmi	\tmp, [\base, #INTCPS_CONTROL]
+		ldr	\irqstat, [\base, #INTCPS_PENDING_IRQ_1] /* IRQ pending reg 1 */
+		ldr	\tmp, [\base, #INTCPS_PENDING_IRQ_2] /* IRQ pending reg 2 */
+		orr	\irqstat, \irqstat, \tmp  /* or them all together */
+		ldr	\tmp, [\base, #INTCPS_PENDING_IRQ_3] /* IRQ pending reg 3 */
+		orrs	\irqstat, \irqstat, \tmp  /* set condition code Z if interrupt */
 		.endm
 
 		.macro	irq_prio_table

Re: ARM: OMAP3: Fix get_irqnr_and_base to clear spurious interrupt bits

[Tony Lindgren]

* Rick Bronson <rick@efn.org> [081022 11:03]:
> 
>   Sorry if I'm late in the game for changes to entry-macro.S but I
> worked on this code a bit ago and have been testing it.  What I have,
> I think, is a little more straight forward.  Note that it doesn't have
> the added mask for the spurious bits, but it does check for
> spurious interrupts and handles them.

Can you refresh it against the current l-o tree? We need to mask out
the spurious bits from the irqnr, otherwise the irqnr data will be
bogus.

Also, AFAIK we don't have infinitely repeating irqs any longer, it's
just an occasional single spurious interrupt.

Tony

> 
>   Rick
> 
> 
> 
> --- linux-omap-2.6/arch/arm/plat-omap/include/mach/entry-macro.S.~1~	2008-10-16 13:33:31.000000000 -0700
> +++ linux-omap-2.6/arch/arm/plat-omap/include/mach/entry-macro.S	2008-10-17 11:38:18.000000000 -0700
> @@ -65,7 +65,11 @@
>  #include <mach/omap34xx.h>
>  #endif
>  
> -#define INTCPS_SIR_IRQ_OFFSET	0x0040		/* Active interrupt number */
> +#define INTCPS_SIR_IRQ_OFFSET	0x0040	/* Active interrupt number */
> +#define INTCPS_CONTROL		0x0048	/* new interrupt agreement bits */
> +#define INTCPS_PENDING_IRQ_1	0x0098	/* IRQ pending reg 1 */
> +#define INTCPS_PENDING_IRQ_2	0x00b8	/* IRQ pending reg 2 */
> +#define INTCPS_PENDING_IRQ_3	0x00d8	/* IRQ pending reg 3 */
>  
>  		.macro	disable_fiq
>  		.endm
> @@ -78,17 +82,19 @@
>  
>  		.macro	get_irqnr_and_base, irqnr, irqstat, base, tmp
>  		ldr	\base, =OMAP2_VA_IC_BASE
> -		ldr	\irqnr, [\base, #0x98] /* IRQ pending reg 1 */
> -		cmp	\irqnr, #0x0
> -		bne	2222f
> -		ldr	\irqnr, [\base, #0xb8] /* IRQ pending reg 2 */
> -		cmp	\irqnr, #0x0
> -		bne	2222f
> -		ldr	\irqnr, [\base, #0xd8] /* IRQ pending reg 3 */
> -		cmp	\irqnr, #0x0
> -2222:
> -		ldrne	\irqnr, [\base, #INTCPS_SIR_IRQ_OFFSET]
> -
> +		ldr	\irqnr, [\base, #INTCPS_SIR_IRQ_OFFSET]
> +		cmp	\irqnr, #0  /* check for negative */
> +		movmi	\tmp, #0x1 /* Ack the spurious irq, this lets it
> +					* generate a bad irq error message,
> +					* but prevents infinitely repeating
> +					* irq.
> +					*/
> +		strmi	\tmp, [\base, #INTCPS_CONTROL]
> +		ldr	\irqstat, [\base, #INTCPS_PENDING_IRQ_1] /* IRQ pending reg 1 */
> +		ldr	\tmp, [\base, #INTCPS_PENDING_IRQ_2] /* IRQ pending reg 2 */
> +		orr	\irqstat, \irqstat, \tmp  /* or them all together */
> +		ldr	\tmp, [\base, #INTCPS_PENDING_IRQ_3] /* IRQ pending reg 3 */
> +		orrs	\irqstat, \irqstat, \tmp  /* set condition code Z if interrupt */
>  		.endm
>  
>  		.macro	irq_prio_table
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

ARM: OMAP3: Fix get_irqnr_and_base to clear spurious interrupt bits

[Tony Lindgren]

[-- Attachment #1: Type: text/plain, Size: 337 bytes --]

Hi all,

Here's a bug fix for the irq -33 issue. So far it looks like the irq
spurious bits just tell that the irq sorting is invalid.

This patch applies after undoing Lauri's patch
5dc857b34441d5c0989b68bf3a488f89983b2645.

Looks like there are still occasional spurious GPT12 interrupts, so
I'm now looking into that.

Regards,

Tony

[-- Attachment #2: 0003-ARM-OMAP3-Fix-get_irqnr_and_base-to-clear-spurious-v2.patch --]
[-- Type: text/x-diff, Size: 1630 bytes --]

commit 3e4291d575f7d694ae1d974a17b4e077b7b721de
Author: Tony Lindgren <tony@atomide.com>
Date:   Mon Oct 20 14:04:52 2008 -0700

    ARM: OMAP3: Fix get_irqnr_and_base to clear spurious interrupt bits
    
    On omap24xx, INTCPS_SIR_IRQ_OFFSET bits [6:0] contains the current
    active interrupt number.
    
    However, on 34xx INTCPS_SIR_IRQ_OFFSET bits [31:7] also contains the
    SPURIOUSIRQFLAG, which gets set if the interrupt sorting information
    is invalid.
    
    If the SPURIOUSIRQFLAG bits are not ignored, the interrupt code will
    occasionally produce a bunch of confusing errors:
    
    irq -33, desc: c02ddcc8, depth: 0, count: 0, unhandled: 0
    ->handle_irq():  c006f23c, handle_bad_irq+0x0/0x22c
    ->chip(): 00000000, 0x0
    ->action(): 00000000
    
    Fix this by masking out only the ACTIVEIRQ bits. Also fix a
    confusing comment.
    
    Signed-off-by: Tony Lindgren <tony@atomide.com>

diff --git a/arch/arm/plat-omap/include/mach/entry-macro.S b/arch/arm/plat-omap/include/mach/entry-macro.S
index a8fca9d..47aa62c 100644
--- a/arch/arm/plat-omap/include/mach/entry-macro.S
+++ b/arch/arm/plat-omap/include/mach/entry-macro.S
@@ -65,7 +65,8 @@
 #include <mach/omap34xx.h>
 #endif
 
-#define INTCPS_SIR_IRQ_OFFSET	0x0040		/* Active interrupt number */
+#define INTCPS_SIR_IRQ_OFFSET	0x0040		/* Active interrupt offset */
+#define	ACTIVEIRQ_MASK		0x7f		/* Active interrupt bits */
 
 		.macro	disable_fiq
 		.endm
@@ -88,6 +89,7 @@
 		cmp	\irqnr, #0x0
 2222:
 		ldrne	\irqnr, [\base, #INTCPS_SIR_IRQ_OFFSET]
+		and	\irqnr, \irqnr, #ACTIVEIRQ_MASK /* Clear spurious bits */
 
 		.endm
 

Re: ARM: OMAP3: Fix get_irqnr_and_base to clear spurious interrupt bits

[Felipe Contreras]

On Tue, Oct 21, 2008 at 7:58 AM, Tony Lindgren <tony@atomide.com> wrote:
> Hi all,
>
> Here's a bug fix for the irq -33 issue. So far it looks like the irq
> spurious bits just tell that the irq sorting is invalid.
>
> This patch applies after undoing Lauri's patch
> 5dc857b34441d5c0989b68bf3a488f89983b2645.

You mean?
3da0e10243d075b905dfa8f1b4a6cb3694ab2ce0

> Looks like there are still occasional spurious GPT12 interrupts, so
> I'm now looking into that.

Works perfectly fine with my DSP tests :)

Thanks!

-- 
Felipe Contreras

Re: ARM: OMAP3: Fix get_irqnr_and_base to clear spurious interrupt bits

[Tony Lindgren]

* Felipe Contreras <felipe.contreras@gmail.com> [081021 13:09]:
> On Tue, Oct 21, 2008 at 7:58 AM, Tony Lindgren <tony@atomide.com> wrote:
> > Hi all,
> >
> > Here's a bug fix for the irq -33 issue. So far it looks like the irq
> > spurious bits just tell that the irq sorting is invalid.
> >
> > This patch applies after undoing Lauri's patch
> > 5dc857b34441d5c0989b68bf3a488f89983b2645.
> 
> You mean?
> 3da0e10243d075b905dfa8f1b4a6cb3694ab2ce0

Oops yeah.

> > Looks like there are still occasional spurious GPT12 interrupts, so
> > I'm now looking into that.
> 
> Works perfectly fine with my DSP tests :)

Thanks for testing, good to hear.

Tony

Re: ARM: OMAP3: Fix get_irqnr_and_base to clear spurious interrupt bits

[Felipe Contreras]

On Tue, Oct 21, 2008 at 11:37 PM, Tony Lindgren <tony@atomide.com> wrote:
> * Felipe Contreras <felipe.contreras@gmail.com> [081021 13:09]:
>> On Tue, Oct 21, 2008 at 7:58 AM, Tony Lindgren <tony@atomide.com> wrote:
>> > Hi all,
>> >
>> > Here's a bug fix for the irq -33 issue. So far it looks like the irq
>> > spurious bits just tell that the irq sorting is invalid.
>> >
>> > This patch applies after undoing Lauri's patch
>> > 5dc857b34441d5c0989b68bf3a488f89983b2645.
>>
>> You mean?
>> 3da0e10243d075b905dfa8f1b4a6cb3694ab2ce0
>
> Oops yeah.
>
>> > Looks like there are still occasional spurious GPT12 interrupts, so
>> > I'm now looking into that.
>>
>> Works perfectly fine with my DSP tests :)
>
> Thanks for testing, good to hear.

Hm, I forgot to revert acb7f8, so the test is not valid. I will try
again tomorrow.

-- 
Felipe Contreras

Re: ARM: OMAP3: Fix get_irqnr_and_base to clear spurious interrupt bits

[Tony Lindgren]

* Felipe Contreras <felipe.contreras@gmail.com> [081021 14:34]:
> On Tue, Oct 21, 2008 at 11:37 PM, Tony Lindgren <tony@atomide.com> wrote:
> > * Felipe Contreras <felipe.contreras@gmail.com> [081021 13:09]:
> >> On Tue, Oct 21, 2008 at 7:58 AM, Tony Lindgren <tony@atomide.com> wrote:
> >> > Hi all,
> >> >
> >> > Here's a bug fix for the irq -33 issue. So far it looks like the irq
> >> > spurious bits just tell that the irq sorting is invalid.
> >> >
> >> > This patch applies after undoing Lauri's patch
> >> > 5dc857b34441d5c0989b68bf3a488f89983b2645.
> >>
> >> You mean?
> >> 3da0e10243d075b905dfa8f1b4a6cb3694ab2ce0
> >
> > Oops yeah.
> >
> >> > Looks like there are still occasional spurious GPT12 interrupts, so
> >> > I'm now looking into that.
> >>
> >> Works perfectly fine with my DSP tests :)
> >
> > Thanks for testing, good to hear.
> 
> Hm, I forgot to revert acb7f8, so the test is not valid. I will try
> again tomorrow.

Well so far the only difference in my tests have been that with
strongly ordered patch there are no spurious irq 95 interrupts,
while without the strongly ordered patch there are occasional
spurious irq 95 interrupts.

These irq 95 interrupts without the strongly ordered patch are
strange as I don't have GPT12 enabled. Also, when they occur,
the INTCPS_SIR_IRQ bits for SPURIOUSIRQFLAG are set to 0x3ffffff
instead of the normal 0 or 1.

Anybody have an idea whtat the SPURIOUSIRQFLAG bits are
supposed to tell in addition to the priority sorting information
being valid or not?

The spurious interrupts show up easily with Natan's DSP ping
test. There's about one spurious irq 95 every two seconds
or so. The system still keeps working normally.

Anyways, I'll revert the earlier patch from Lauri, and apply
this one. Will also add it to omap-fixes queue for the mainline
kernel.

Regards,

Tony

Re: ARM: OMAP3: Fix get_irqnr_and_base to clear spurious interrupt bits

[Tony Lindgren]

* Tony Lindgren <tony@atomide.com> [081021 15:02]:
> * Felipe Contreras <felipe.contreras@gmail.com> [081021 14:34]:
> > On Tue, Oct 21, 2008 at 11:37 PM, Tony Lindgren <tony@atomide.com> wrote:
> > > * Felipe Contreras <felipe.contreras@gmail.com> [081021 13:09]:
> > >> On Tue, Oct 21, 2008 at 7:58 AM, Tony Lindgren <tony@atomide.com> wrote:
> > >> > Hi all,
> > >> >
> > >> > Here's a bug fix for the irq -33 issue. So far it looks like the irq
> > >> > spurious bits just tell that the irq sorting is invalid.
> > >> >
> > >> > This patch applies after undoing Lauri's patch
> > >> > 5dc857b34441d5c0989b68bf3a488f89983b2645.
> > >>
> > >> You mean?
> > >> 3da0e10243d075b905dfa8f1b4a6cb3694ab2ce0
> > >
> > > Oops yeah.
> > >
> > >> > Looks like there are still occasional spurious GPT12 interrupts, so
> > >> > I'm now looking into that.
> > >>
> > >> Works perfectly fine with my DSP tests :)
> > >
> > > Thanks for testing, good to hear.
> > 
> > Hm, I forgot to revert acb7f8, so the test is not valid. I will try
> > again tomorrow.
> 
> Well so far the only difference in my tests have been that with
> strongly ordered patch there are no spurious irq 95 interrupts,
> while without the strongly ordered patch there are occasional
> spurious irq 95 interrupts.
> 
> These irq 95 interrupts without the strongly ordered patch are
> strange as I don't have GPT12 enabled. Also, when they occur,
> the INTCPS_SIR_IRQ bits for SPURIOUSIRQFLAG are set to 0x3ffffff
> instead of the normal 0 or 1.
> 
> Anybody have an idea whtat the SPURIOUSIRQFLAG bits are
> supposed to tell in addition to the priority sorting information
> being valid or not?
> 
> The spurious interrupts show up easily with Natan's DSP ping
> test. There's about one spurious irq 95 every two seconds
> or so. The system still keeps working normally.
> 
> Anyways, I'll revert the earlier patch from Lauri, and apply
> this one. Will also add it to omap-fixes queue for the mainline
> kernel.

BTW, looks like marking just the L4 as MT_MEMORY_SO is enough to
get rid of the spurious irq 95 interrupts.

> Regards,
> 
> Tony

Re: ARM: OMAP3: Fix get_irqnr_and_base to clear spurious interrupt bits

[Felipe Contreras]

On Wed, Oct 22, 2008 at 1:02 AM, Tony Lindgren <tony@atomide.com> wrote:
> * Felipe Contreras <felipe.contreras@gmail.com> [081021 14:34]:
>> On Tue, Oct 21, 2008 at 11:37 PM, Tony Lindgren <tony@atomide.com> wrote:
>> > * Felipe Contreras <felipe.contreras@gmail.com> [081021 13:09]:
>> >> On Tue, Oct 21, 2008 at 7:58 AM, Tony Lindgren <tony@atomide.com> wrote:
>> >> > Hi all,
>> >> >
>> >> > Here's a bug fix for the irq -33 issue. So far it looks like the irq
>> >> > spurious bits just tell that the irq sorting is invalid.
>> >> >
>> >> > This patch applies after undoing Lauri's patch
>> >> > 5dc857b34441d5c0989b68bf3a488f89983b2645.
>> >>
>> >> You mean?
>> >> 3da0e10243d075b905dfa8f1b4a6cb3694ab2ce0
>> >
>> > Oops yeah.
>> >
>> >> > Looks like there are still occasional spurious GPT12 interrupts, so
>> >> > I'm now looking into that.
>> >>
>> >> Works perfectly fine with my DSP tests :)
>> >
>> > Thanks for testing, good to hear.
>>
>> Hm, I forgot to revert acb7f8, so the test is not valid. I will try
>> again tomorrow.
>
> Well so far the only difference in my tests have been that with
> strongly ordered patch there are no spurious irq 95 interrupts,
> while without the strongly ordered patch there are occasional
> spurious irq 95 interrupts.
>
> These irq 95 interrupts without the strongly ordered patch are
> strange as I don't have GPT12 enabled. Also, when they occur,
> the INTCPS_SIR_IRQ bits for SPURIOUSIRQFLAG are set to 0x3ffffff
> instead of the normal 0 or 1.
>
> Anybody have an idea whtat the SPURIOUSIRQFLAG bits are
> supposed to tell in addition to the priority sorting information
> being valid or not?
>
> The spurious interrupts show up easily with Natan's DSP ping
> test. There's about one spurious irq 95 every two seconds
> or so. The system still keeps working normally.

I've reverted the strongly ordered patch and I'm not getting any IRQ
issues with any DSP tests, including the ping one.

I'm using the latest patches from Hiroshi (20081021), so maybe that
has something to do with it?

-- 
Felipe Contreras

Re: ARM: OMAP3: Fix get_irqnr_and_base to clear spurious interrupt bits

[Nathan Monson]

On Wed, Oct 22, 2008 at 7:46 AM, Felipe Contreras
<felipe.contreras@gmail.com> wrote:
> I've reverted the strongly ordered patch and I'm not getting any IRQ
> issues with any DSP tests, including the ping one.
>
> I'm using the latest patches from Hiroshi (20081021), so maybe that
> has something to do with it?

I've also reverted the strongly ordered patch.  While I can't do
anything that freezes the kernel anymore, I can still cause two kinds
of endless interrupts on Angstrom:

1) About 1 in 10 boots generates these messages endlessly:

__ratelimit: 1518265 callbacks suppressed
omapfb omapfb: irq error status 4000
omapfb omapfb: irq error status 4022

Tony sent me some debug code which shows the register values when this occurs:
XXX 95mask: 0xffffffdf 95 0x3ffffff
XXX 95ack: 0xffffffdf 95 0x3ffffff

This can be triggered even without the DSP patches.

Before Tony's latest work, this would just spiral out into irq -33s
and kill the kernel.  Now it just slows things down, which is a good
improvement.

I can't reproduce this with the S-O patch.

2) I still get spurious interrupts while running the DSP ping.out
test, but they are also handled better.  No slow down occurs.
However, I can get endless interrupts  by unplugging/replugging my USB
hub.  Again, the endless interrupts slow things down a lot, but no
longer kill the system like before.

I can't reproduce this with the S-O patch.

Let me know if there are further patches worth testing without S-O.
For now, I'm back to S-O to allow me to keep working.

- Nathan

Re: ARM: OMAP3: Fix get_irqnr_and_base to clear spurious interrupt bits

[Felipe Contreras]

On Thu, Oct 23, 2008 at 12:30 AM, Nathan Monson <nmonson@gmail.com> wrote:
> On Wed, Oct 22, 2008 at 7:46 AM, Felipe Contreras
> <felipe.contreras@gmail.com> wrote:
>> I've reverted the strongly ordered patch and I'm not getting any IRQ
>> issues with any DSP tests, including the ping one.
>>
>> I'm using the latest patches from Hiroshi (20081021), so maybe that
>> has something to do with it?
>
> I've also reverted the strongly ordered patch.  While I can't do
> anything that freezes the kernel anymore, I can still cause two kinds
> of endless interrupts on Angstrom:
>
> 1) About 1 in 10 boots generates these messages endlessly:
>
> __ratelimit: 1518265 callbacks suppressed
> omapfb omapfb: irq error status 4000
> omapfb omapfb: irq error status 4022
>
> Tony sent me some debug code which shows the register values when this occurs:
> XXX 95mask: 0xffffffdf 95 0x3ffffff
> XXX 95ack: 0xffffffdf 95 0x3ffffff
>
> This can be triggered even without the DSP patches.
>
> Before Tony's latest work, this would just spiral out into irq -33s
> and kill the kernel.  Now it just slows things down, which is a good
> improvement.
>
> I can't reproduce this with the S-O patch.
>
> 2) I still get spurious interrupts while running the DSP ping.out
> test, but they are also handled better.  No slow down occurs.
> However, I can get endless interrupts  by unplugging/replugging my USB
> hub.  Again, the endless interrupts slow things down a lot, but no
> longer kill the system like before.
>
> I can't reproduce this with the S-O patch.
>
> Let me know if there are further patches worth testing without S-O.
> For now, I'm back to S-O to allow me to keep working.

Which DSP patches are you using?

I haven't been able to reproduce this with Tony's irq mask patch,
latest DSP patches, and removing S-O patch.

-- 
Felipe Contreras