"Felipe Contreras" <felipe.contreras@xxxxxxxxx> writes: > Now I'm getting a bunch of these errors apparently when shuffling > memory too fast: > irq -33, desc: c0335cf8, depth: 0, count: 0, unhandled: 0 > ->handle_irq(): c00744e0, handle_bad_irq+0x0/0x22c > ->chip(): 00000000, 0x0 > ->action(): 00000000 I've had this problem regularly while using linux-omap .26 and .27 on the BeagleBoard. I turned off framebuffer support after seeing your message and it seemed to help. (Hard to tell since it is random.) Now I'm using DSP Bridge and the problem is back. In fact, the problem occurs within a minute or two of running code on the DSP. On the BeagleBoard list, Pratheesh Gangadhar said that mapping I/O regions as Strongly Ordered suppresses this problem: http://groups.google.com/group/beagleboard/browse_thread/thread/23e1c95b4bfb09b5/70d12dca569ca503?show_docid=70d12dca569ca503 > This proves that these spurious interrupts are side effect of using posted > writes to acknowledge/clear the interrupt status in the peripheral. Is there anyone who knows their way around mmu.c that could create a quick and dirty patch to use Strongly Ordered I/O on OMAP3? I'd like to test it with the DSP. - Nathan -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
