Angstrom Gets IRQ -33 Errors
Geof Cohler
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
Koen Kooi
down yet.
regards,
Koen
Pratheesh Gangadhar
Regards,
Pratheesh
(1) http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0290g/Babhcffj.html
Leon Woestenberg
On Wed, Oct 8, 2008 at 7:24 PM, Pratheesh Gangadhar
<pratheesh...@gmail.com> wrote:
> On Wed, Oct 8, 2008 at 10:28 PM, Koen Kooi <koen...@gmail.com> wrote:
>> On 8 okt, 18:48, Geof Cohler <g.coh...@computer.org> wrote:
>> > 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.
>
> 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.
>
Thanks for the info, reading this sub topic:
http://infocenter.arm.com/help/topic/com.arm.doc.ddi0290g/Babcijbf.html#id4387599
Assuming the memory area is non-shared*, a device read (non-shared)
would commit the (posted) write and clear the interrupt.
*which may be a false assumption
Regards,
--
Leon
Koen Kooi
On 8 okt, 20:08, "Leon Woestenberg" <leon.woestenb...@gmail.com>
wrote:
>
> On Wed, Oct 8, 2008 at 7:24 PM, Pratheesh Gangadhar
>
> >> On 8 okt, 18:48, Geof Cohler <g.coh...@computer.org> wrote:
> >> > 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.
>
> > 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.
>
> Thanks for the info, reading this sub topic:
>
> Assuming the memory area is non-shared*, a device read (non-shared)
> would commit the (posted) write and clear the interrupt.
>
> *which may be a false assumption
regards,
Koen
Felipe Contreras
Geof Cohler
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
>
> regards,
>
> Koen- Hide quoted text -
>
> - Show quoted text -
Koen Kooi
On 9 okt, 13:54, Geof Cohler <g.coh...@computer.org> wrote:
> 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.
Geof Cohler
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
TK, Pratheesh Gangadhar
Is there any patches missing for audio driver ?
Is this a reproducible problem for every one using mplayer with audio ?
Regards,
Pratheesh
nmonson
> I rebuilt my .27 kernel from scratch including the new IRQ-33 fix.
>
> 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.
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
Geof Cohler
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
JustinLove
> 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
--
Justin Love
Creative Electronics & Software
650 Sundown Road
South Elgin, IL 60177
Phone (847) 695-0023
FAX (847) 695-0483