Angstrom Gets IRQ -33 Errors

GoogleGroups
1

Often when I run mplayer (using the Angstrom Demo), the system will
hang up with a series of IRQ-33 errors. This usually requires me to
reboot to cure the problem.

irq -33, desc: c03ffe28, depth: 0, count: 0, unhandled: 0
->handle_irq(): c007c118, handle_bad_irq+0x0/0x228
->chip(): 00000000, 0x0
->action(): 00000000

Any ideas on what's causing these? I'm certainly loading the system
heavily with mplayer.

Thanks very much.

Best regards,
Geof

2

Rumour has it that it's dispc related, but AIUI no-one has tracked it
down yet.

regards,

Koen

3

Often when I run mplayer (using the Angstrom Demo), the system will
hang up with a series of IRQ-33 errors. This usually requires me to
reboot to cure the problem.

irq -33, desc: c03ffe28, depth: 0, count: 0, unhandled: 0
->handle_irq(): c007c118, handle_bad_irq+0x0/0x228
->chip(): 00000000, 0x0
->action(): 00000000

Any ideas on what’s causing these? I’m certainly loading the system
heavily with mplayer.

Rumour has it that it’s dispc related, but AIUI no-one has tracked it
down yet.

regards,

Koen

This error can be suppressed by making certain I/O regions Strongly Ordered (1) instead of default MT_DEVICE - I can’t say for sure whether this is the perfect solution - but it proves that these spurious interrupts are side effect of using posted writes to acknowledge/clear the interrupt status in the peripheral.

Regards,
Pratheesh

(1) http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0290g/Babhcffj.html

4

Hello,

5

Try http://dominion.thruhere.net/koen/OE/uImage-2.6.26+2.6.27-rc7+r14+gite1c49d7d22af768188e2a54c167ed79919361e55-r14-beagleboard.bin

regards,

Koen

6

This patch seems to work:
http://marc.info/?l=linux-omap&m=122349732218782&w=2

7

Hi,

I tried the 27 image you listed above. I didn't get IRQ-33 errors,
but... I couldn't get mplayer to run for more than about 30 seconds
without hanging the machine. So while perhaps fixing the IRQ problem,
it has perhaps created a worse problem. I'll give the patch from
Pratesh a try.

Best regards,
Geof

8

That kernel already has the patch from Prateesh applied.

9

Hi,

I rebuilt my .27 kernel from scratch including the new IRQ-33 fix.

The good news:
- I don't appear to be getting the IRQ-33s anymore.
- I ran mplayer -nosound movie.mp4 -loop 0 and it ran for an hour or
two without a hitch.
- omapfbplay works even better than it did!

The bad news:
- Mplayer no longer works for more than a couple of seconds without
hanging when playing both sound and video. It goes into a state where
the system is hosed (i.e. mouse cursor is not working), and it sounds
like a record skipping (for those who can remember that) playing the
same one second or so of sound over and over again.

So I'm afraid that the shotgun approach of the IRQ_33 patch may have
been too broad an approach.

Any ideas?

Thanks.
Geof

10

Other possibility is that - this change is exposing bugs in other drivers :slight_smile:
Is there any patches missing for audio driver ?

Is this a reproducible problem for every one using mplayer with audio ?

Regards,
Pratheesh

11

Did sound work better for you with .27 before the patch? I know .27
broke ALSA sound. There is a workaround posted here:
http://elinux.org/BeagleBoardFAQ#Sound_at_git_kernel

Hopefully this is a known issue and not a new one.

- Nathan

12

In some ways, yes, in some ways no. With the .26 kernel, mplayer will
run for longer before crashing the system, in a different way. So
here's what I have observed so far:

.26 kernel (linux-omap2):
- Can run Audio by itself for random amount of time, and eventually
it will crash.
- Can run Video by itself for random amount of time, and eventually
it will crash.
- Can run Video and Audio for random amount of time, and eventually
it will crash.

.27 kernel (linux-omap with post Oct 9 git)
- Can run Audio by itself and it doesn't seem to crash anymore.
- Can run Video by itself and it doesn't seem to crash anymore.
- Can run Video and Audio for random amount of time, and it crashes
-- seems to be more quickly than in the .26 kernel case.

So overall, .27 is an improvement. But for mplayer, I think it shows
up another bug more quickly than the .26 kernel did.

I'll try -ao oss, but that has never had any effect in the past.

Best regards,
Geof

13

Geof Cohler wrote:

The good news:
- I don't appear to be getting the IRQ-33s anymore.

The bad news:
- Mplayer no longer works for more than a couple of seconds without

I froze my OE build a while back as recommended. Since that time there was some discussion [1] on infinite irq -33 errors when running mplayer. I've started seeing this more lately, and the previous discussion thread kind of seemed to leave the issue hanging. Has there been enough improvement to make risking the build cycle worthwhile?

[1] http://groups.google.com/group/beagleboard/browse_thread/thread/23e1c95b4bfb09b5/de4ced19eb7b9652