> 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 shoul
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
> 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 thing
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 th
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] show_stack+0x80/
