Ok, I'm not familiar with that PIC. You need to check what's going on
between the PIC, your interrupt source and the kernel.
Normally, if it's an edge interrupt, it's a single event that gets
latched by the PIC. The kernel will then call ack() on that PIC driver
(irq_chip) which should
On Fri, 2011-07-08 at 09:26 +0200, Guillaume Dargaud wrote:
What is Xad. ? (btw, coding style FAIL !)
That's the struct I use to access the control registers of the hardware.
About the coding style, don't worry it's never going to make it into
mainstream as there's only one piece of that
What is Xad. ? (btw, coding style FAIL !)
That's the struct I use to access the control registers of the hardware.
About the coding style, don't worry it's never going to make it into mainstream
as there's only one piece of that
hardware ever built ! (which is also why I didn't respect things
I'll expand a bit on my previous message. Here's a more detailed dump of what
happens when my system receives a second
interrupt (the 1st one works fine) from my hardware:
[ 263.586996] do_IRQ: stack overflow: 1920
[ 263.590785] Call Trace:
[ 263.593275] [c7792780] [c00073ac]
On Tue, 2011-07-05 at 16:19 +0200, Guillaume Dargaud wrote:
Hello all,
one of my drivers is causing a kernel panic and I _think_ it happens in the
1st call to the interrupt routine.
What kind of information can I extract from the following ?
Is it like a core dump that I can load with the
Hello all,
one of my drivers is causing a kernel panic and I _think_ it happens in the 1st
call to the interrupt routine.
What kind of information can I extract from the following ?
Is it like a core dump that I can load with the executable in the debugger to
know exactly what happened (I doubt
