Skip to contentSkip to conversation

ARM: OMAP3: Fix get_irqnr_and_base to clear spurious interrupt bits

PATCH Tony Lindgren 3 participants 9 messages Oct 21, 2008 – Oct 22, 2008

Subsystems (2)
Arm (32-bit) Arm sub-architectures
lore
Share & tools
lore

Tony Lindgren

author
#0 lore raw

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

commit 3e4291d575f7d694ae1d974a17b4e077b7b721de

Author: Tony Lindgren <[email protected]>
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 <[email protected]>
arch/arm/plat-omap/include/mach/entry-macro.S +3 -1
index a8fca9d..47aa62c 100644
@@ -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
#1 lore raw
Quoted 7 lines · Tony Lindgren

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

Quoted 2 lines

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

Works perfectly fine with my DSP tests :)

Thanks!

Signature · 1 line
Felipe Contreras
author
#2 lore raw
Quoted 11 lines · Felipe Contreras
Quoted 7 lines · Tony Lindgren

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.

Quoted 4 lines
Quoted 2 lines

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

#3 lore raw
Quoted 13 lines · Tony Lindgren
Quoted 11 lines · Felipe Contreras
Quoted 7 lines · Tony Lindgren

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

Quoted 8 lines

Oops yeah.

Quoted 4 lines
Quoted 2 lines

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.

Signature · 1 line
Felipe Contreras
author
#4 lore raw
Quoted 19 lines · Felipe Contreras
Quoted 18 lines · Tony Lindgren
Quoted 11 lines · Felipe Contreras
Quoted 7 lines · Tony Lindgren

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.

Quoted 3 lines
Quoted 2 lines

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

Quoted 6 lines
Quoted 3 lines
Quoted 1 line

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

author
#5 lore raw
Quoted 41 lines · Tony Lindgren
Quoted 19 lines · Felipe Contreras
Quoted 18 lines · Tony Lindgren
Quoted 11 lines · Felipe Contreras
Quoted 7 lines · Tony Lindgren

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.

Quoted 3 lines
Quoted 2 lines

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

Quoted 6 lines
Quoted 3 lines
Quoted 1 line

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?

Quoted 7 lines

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.

Quoted 3 lines

Regards,

Tony

#6 lore raw
In reply to Tony Lindgren
Quoted 37 lines · Tony Lindgren
Quoted 19 lines · Felipe Contreras
Quoted 18 lines · Tony Lindgren
Quoted 11 lines · Felipe Contreras
Quoted 7 lines · Tony Lindgren

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.

Quoted 3 lines
Quoted 2 lines

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

Quoted 6 lines
Quoted 3 lines
Quoted 1 line

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.

Quoted 7 lines

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?

Signature · 1 line
Felipe Contreras
#7 lore raw
Quoted 5 lines · Felipe Contreras

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

#8 lore raw
Quoted 36 lines · Nathan Monson
Quoted 5 lines · Felipe Contreras

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.

Quoted 4 lines

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.

Signature · 1 line
Felipe Contreras