On 04/28/2011 05:16 PM, Gilles Chanteperdrix wrote: > Ok. Better try without this patch first, then try reapplying the patch > when you are certain that everything else works correctly. The patch > enables some assembly code that was never actually tested. On my side, I > will try and test it separately. So I tried to trace the kernel using gdb and jtag.
It enters the interrupt handler over and over again. If I set a breakpoint at __ipipe_grab_irq, I see the following: __ipipe_grab_irq (irq=37, regs=0xc3dd3f08) __ipipe_grab_irq (irq=30, regs=0xc3dd3f08) __ipipe_grab_irq (irq=37, regs=0xc3dd3f08) __ipipe_grab_irq (irq=30, regs=0xc3dd3f08) and so on. Note the strict order of IRQs 30 and 37. According to /proc/interrupts running vanilla kernel, these IRQs are: 30: 36105 s3c S3C2410 Timer Tick 37: 12464 s3c s3c-mci As far as I can see, these two IRQs are both handled by the same code in ipipe. And they are both periodic and occur so frequently that they interrupt each other's handler. Looks like they aren't masked properly for some reason. So the kernel loops infinitely in these two interrupt handlers and does never exit them! -- Alex _______________________________________________ Adeos-main mailing list Adeos-main@gna.org https://mail.gna.org/listinfo/adeos-main
